@wowok/agent-mcp 3.3.6 → 3.3.8

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

@@ -37,13 +37,32 @@
     "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_concurrent_orders_coverable": "How many simultaneous ceiling-sized claims the fund can pay: floor(fund / (3x highest SKU)). The buy gate only covers 3x ONE order — concurrent claims beyond this count abort (E_COMPENSATION_NOT_MATCH) until a manual top-up (PLAN-K2, b6-11)",
     "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)",
+    "reward_bounty_amount": "Largest per-claim bounty across the plan's reward guard_add mounts (Fixed amounts, smallest units) — absent when the plan mounts no bounty (T-02, bsn7-tn-261026)",
+    "reward_funding_amount": "Sum of parseable reward-pool funding (coin_add steps on reward targets, smallest units)",
+    "reward_max_claims": "How many full-bounty claims the current funding can pay: floor(funding / bounty)",
+    "lowest_sku_price": "Cheapest POSITIVE SKU price on the plan's sales catalog (same two legal sites the PLAN-K2 ceiling parser reads; a 0-price SKU is dead stock, F-BS-76)",
+    "reward_scale_breach": "The bounty exceeds half the cheapest SKU price — every claimed order pays out more than the sale earns, a bounty-farm target (T-02; judged ONLY when both sides parse)",
+    "reward_scale_ratio_display": "Human-readable bounty-to-cheapest-SKU ratio",
+    "reward_scale_unverifiable": "A bounty mount exists but the catalog has no parseable price — the scale judgment is deferred, stated explicitly (T-02 fallback, never silence)",
+    "first_arb_exit_node": "First settled/refund-class node with an outgoing edge whose guard queries the arbitration promise family (arb.indemnity / arb.order / arb.status / order.dispute) — a post-settlement arbitration re-route (FUND-ZERO-01 judgment gate)",
+    "fund_arb_route_unfunded": "A post-settlement arbitration re-route exists AND the compensation pool is absent or deposits 0 — the ruling payout aborts 27 (E_COMPENSATION_NOT_MATCH), so the promised exit is dead by construction (FUND-ZERO-01)",
+    "entry_no_open_exit": "The order-landing node (entry-edge target) exits only through CLOSING time windows (Clock <= anchor legs, no opening leg, no unguarded alternative) — once a window closes nothing can advance the order and the entry escrow is locked (ENTRY-ABANDON-01, gf26 GF2-30)",
+    "entry_strand_node": "First stranded entry node name (ENTRY-ABANDON-01 judgment gate)",
+    "arb_promise_without_settle_rail": "A machine guard reads the arbitration ruling family while NO $ref-visible allocator row releases money on the ruling (none reads the family, none rides the ruling edge node-free, and the ruling edge's destination has no FUND-EXIT-01-style allocator coverage); guard_key-declared rails are plan-opaque and left to the freeze gate — the verdict moves state, never money (POST-ARB-SETTLE-01, gf26 GF2-31)",
+    "arb_promise_node": "First node whose exit edge carries the arbitration-promise guard (POST-ARB-SETTLE-01 judgment gate)",
+    "arb_key_plane_opaque": "The machine carries arbitration-promise guards while the allocator rail plane carries guard_key declarations — rails the $ref plane cannot verify, so the POST-ARB-SETTLE-01 verdict rule stays silent there by ruling; this shape is the freeze gate's red line: ARB-KEY-PLANE-01 fires high and preflightPlan refuses the publish until the keys resolve into structured guard steps (user ruling 2026-10-26)",
+    "arb_key_plane_node": "First node whose exit edge carries the arbitration-promise guard (ARB-KEY-PLANE-01 judgment gate)",
     "repo_policy_keys_display": "Comma-joined policy names declared by the plan's repository create steps (present only when at least one policy exists — the REPO-GATE-KEY-01 judgment gate)",
     "repo_gate_key_unbacked_count": "Composite where-query scans over a plan-local repository whose static key no declared policy uses (REPO-GATE-KEY-01, ZR-32)",
     "first_repo_gate_key_unbacked": "First unbacked gate key, rendered as 'key' in guard 'step-id'",
     "repo_gate_key_unbacked_display": "Comma-joined list of ALL unbacked gate keys",
-    "sales_step_present": "The plan materializes at least one sellable SKU (a service create with a non-empty sales list, or a configure step with method 'sales') — the order entry's existence predicate (PLAN-SALES-01)"
+    "sales_step_present": "The plan materializes at least one sellable SKU (a service create with a non-empty sales list, or a configure step with method 'sales') — the order entry's existence predicate (PLAN-SALES-01)",
+    "guard_reach_contradiction_count": "Root-AND-chain legs carrying proof-level structural unreachability (ordering interval crossing; == to two different numeric constants or to opposite Bools; == X conjoined with a strict ordering past X; same-binding self-comparison with a strict direction) — the guard predicate is unsatisfiable by construction (GUARD-REACH-01, S3 plane)",
+    "first_guard_reach_contradiction": "First contradiction, rendered as: guard 'step-id' (channel): OP X contradicts OP X — unsatisfiable",
+    "guard_reach_contradiction_display": "Semicolon-joined list of ALL proof-level unreachability contradictions in the plan's guard roots"
   },
   "rules": [
     {
@@ -99,6 +118,74 @@
         }
       ]
     },
+    {
+      "rule_id": "FUND-ZERO-01",
+      "dimension": "fund_flow",
+      "trigger": "The machine routes a post-settlement arbitration re-route (an arbitration-promise guard — arb.indemnity / arb.order / arb.status / order.dispute — on an edge leaving a settled/refund-class node) while the compensation pool is never funded. service::compensation_claim pays the ruling from service.compensation_fund (service.move:589-602) and an underfunded pool aborts the payout with code 27 (E_COMPENSATION_NOT_MATCH, claim left unconsumed); the escrow behind a settled/refunded node is structurally drained, so with a zero or absent fund the promised exit is dead by construction (gf26-tn-261026 GF2-02: a 0-fund shop published and the buyer's only remedy had no money behind it).",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "fund_arb_route_unfunded", "op": "truthy" }, { "field": "fund_topup_present", "op": "falsy" } ] },
+          "level": "critical",
+          "title": "Post-settlement arbitration re-route from '${first_arb_exit_node}' with NO compensation fund",
+          "description": "The plan gates an exit edge leaving '${first_arb_exit_node}' on an arbitration ruling. That ruling pays through service::compensation_claim, which draws ONLY from service.compensation_fund — this plan never creates one (no compensation_fund_add step). The escrow is already drained at that node, so the buyer's remedy has zero money behind it: the payout aborts with code 27 even when the ruling is valid.",
+          "mitigation": "Add a configure step with method 'compensation_fund_add' and a balance >= the largest single-order exposure (the award ceiling is 3x the order amount, arb.move MAX_INDEMNITY_MULTIPLE), or rebuild without the post-settlement arbitration edge so the remedy does not depend on the fund.",
+          "stakeholders": ["merchant", "customer"]
+        },
+        {
+          "when": { "all": [ { "field": "fund_arb_route_unfunded", "op": "truthy" }, { "field": "fund_topup_present", "op": "truthy" }, { "field": "fund_topup_amount", "op": "eq", "value": 0 } ] },
+          "level": "critical",
+          "title": "Post-settlement arbitration re-route from '${first_arb_exit_node}' with a ZERO compensation fund",
+          "description": "The plan gates an exit edge leaving '${first_arb_exit_node}' on an arbitration ruling, and its compensation_fund_add step deposits 0 — the fund exists but pays nothing. compensation_claim aborts with code 27 (E_COMPENSATION_NOT_MATCH) on any payout attempt, so the promised exit is still dead by construction.",
+          "mitigation": "Raise the compensation_fund_add balance to a real amount (>= the largest single-order exposure; the chain award ceiling is 3x the order amount), or remove the arbitration-gated exit edge.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "ENTRY-ABANDON-01",
+      "dimension": "fund_flow",
+      "trigger": "The order-landing node — the target of the machine entry edge (prev_node \"\") — exits only through CLOSING time-window guards (logic_as_u256_lesser_or_equal[Clock, anchor], no opening leg, no unguarded alternative): once a window closes every forward aborts, nothing can advance the order, and the escrow taken at entry is locked by construction (gf26-tn-261026 GF2-30: a 7.65 WOW pledge entered by a second transaction with no abandon-refund edge; machines and guard tables freeze at publish, so the missing recovery edge cannot be added later). Dead-end entries (zero exits) belong to the dead-end scanner, not this rule.",
+      "cases": [
+        {
+          "when": { "field": "entry_no_open_exit", "op": "truthy" },
+          "level": "high",
+          "title": "Entry node '${entry_strand_node}' has no exit that opens after its window",
+          "description": "Every forward leaving '${entry_strand_node}' — the node orders land on at entry — is gated by a closing time window (Clock <= anchor) with no opening leg and no unguarded alternative. Once the window passes the guard aborts forever: the order can never advance, and the escrow collected at entry is locked with no abandon/refund path. This is the GF2-30 live loss shape (7.65 WOW); shipping it bakes the lockup in permanently.",
+          "mitigation": "Add a self-healing exit from '${entry_strand_node}' gated on an OPENING window (logic_as_u256_greater_or_equal[Clock, anchor] — the abandon/refund edge that fires when the claim window elapses) targeting a fund-bearing node, so the escrow always keeps an after-window path; or leave one exit unguarded / gated on an any-time condition.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "POST-ARB-SETTLE-01",
+      "dimension": "fund_flow",
+      "trigger": "A machine guard reads the arbitration ruling family (arb.indemnity / arb.order / arb.status / order.dispute) while no allocator row releases money on that ruling — none reads the family, none rides the ruling edge node-free, and the ruling edge's destination node is covered by no allocator in the FUND-EXIT-01 dual-shape semantics (pinned by an allocator guard, or node-free-covered by an unconstrained allocator guard mounted on one of its inbound edges — the canonical shape where the ruling re-routes the order into a node the plain refund allocator drains). Judged only on the $ref plane: plans whose allocator rows declare guards by key (guard_key — the template/migration emission) carry a rail plane invisible here and are left to the materialization freeze gate. arb.move rulings only write case state; the payout must exist as a plan rail, so with none the verdict changes state and the escrow never moves (gf26-tn-261026 GF2-31: a ruling that writes status but never releases the money).",
+      "cases": [
+        {
+          "when": { "field": "arb_promise_without_settle_rail", "op": "truthy" },
+          "level": "critical",
+          "title": "Arbitration promise at '${arb_promise_node}' with no ruling-gated settlement leg",
+          "description": "A guard on the forward out of '${arb_promise_node}' reads the arbitration ruling family, promising a ruling-driven outcome — but no allocator row releases money on that ruling: none reads the family, none rides the ruling edge, and the ruling edge's destination node has no allocator coverage (no pin, no node-free refund mount). When the verdict lands the machine changes state and the escrow stays put; the ruling moves nothing. Allocators freeze at publish, so the missing settlement leg cannot be added afterwards.",
+          "mitigation": "Add an allocator row that releases money on the ruling: either a guard reading the arbitration family (arb.order == the order, arb.indemnity some == true) with a payout sharing leg, or route the ruling edge into a node already drained by the refund/settlement rail (an allocator guard pins it, or a node-free allocator guard rides one of its inbound edges). Do not keep a state-only promise.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "ARB-KEY-PLANE-01",
+      "dimension": "fund_flow",
+      "trigger": "The machine carries arbitration-promise guards (arb.indemnity / arb.order / arb.status / order.dispute) while the allocator rail plane carries guard_key declarations (the template/migration emission shape) — rails the $ref plane cannot verify, so a settle leg hiding in a keyed row is invisible here. The POST-ARB-SETTLE-01 verdict stays silent on this shape by ruling (2026-10-26); this rule is the publish-door red line instead: the materialization freeze gate refuses the publish until the keys resolve into structured guard steps whose settle-rail coverage is plan-verifiable.",
+      "cases": [
+        {
+          "when": { "field": "arb_key_plane_opaque", "op": "truthy" },
+          "level": "high",
+          "title": "Arbitration promise at '${arb_key_plane_node}' rides an opaque guard_key rail plane",
+          "description": "A guard on the forward out of '${arb_key_plane_node}' reads the arbitration ruling family, promising a ruling-driven outcome — but this plan's allocator rails are (at least partly) declared by key (guard_key), so the $ref plane cannot verify that any rail releases money on the ruling: a settle leg hiding in a keyed row is invisible to the audit. The state-only verdict risk of POST-ARB-SETTLE-01 cannot be ruled out here, and a failed settle rail would strand the escrow with the verdict unable to move money — with no way to add the settlement leg after publish. This is a publish-door red line — the freeze gate refuses this shape.",
+          "mitigation": "Resolve each guard_key rail into structured guard steps (guardResolutions with kind 'template' or 'inline') before publish, so the settle-rail coverage becomes plan-visible and POST-ARB-SETTLE-01 can judge it; or re-route the ruling edge into a node drained by a $ref-visible allocator row.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
     {
       "rule_id": "UNRESOLVED-GUARD-01",
       "dimension": "composition",
@@ -163,13 +250,13 @@
     {
       "rule_id": "PLAN-K2",
       "dimension": "fund_flow",
-      "trigger": "Compensation-fund sizing guidance (KL-K2 family, re-scoped by b6-11): an award is hard-capped at 3x the order amount at ruling time, so a fund below a planned case's ceiling turns a WON award into an unpayable one (the claim aborts and is NOT consumed). Per-order coverage is ENFORCED at buy time (each order is checked against 3x ITS OWN amount); the plan layer advises sizing on the typical single order instead of the priciest SKU — no cross-SKU subsidy.",
+      "trigger": "Compensation-fund sizing guidance (KL-K2 family, re-scoped by b6-11, demoted to warning by sign-off 5 — dm-mtw-261027): an award is hard-capped at 3x the order amount at ruling time, so a fund below a planned case's ceiling turns a WON award into an unpayable one (the claim aborts and is NOT consumed). Per-order coverage is WARNED at buy time (each order is checked against 3x ITS OWN amount; the order still proceeds); the plan layer advises sizing on the typical single order instead of the priciest SKU — no cross-SKU subsidy.",
       "cases": [
         {
           "when": { "field": "fund_ceiling_breach", "op": "truthy" },
           "level": "medium",
           "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. Disclosure, not a blocker: under-covered ORDERS are refused at buy time (per-order gate), so no buyer enters a knowingly unprotected order.",
+          "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. Disclosure, not a blocker: under-covered ORDERS proceed with a buy-time warning (the per-order gate was demoted to a warning by sign-off 5 — dm-mtw-261027), so a buyer CAN enter a knowingly under-covered order — quote-time disclosure (max_coverable_order) is the buyer's protection. Concurrency headroom: this pool can pay ${fund_concurrent_orders_coverable} simultaneous ceiling-sized claim(s) — concurrent claims beyond that abort until a manual top-up.",
           "mitigation": "Raise the compensation_fund input toward the ceiling (${fund_ceiling_basis}). Sizing is per-order now: 3x the typical single order keeps any single ruling payable; above that only buys tolerance for CONCURRENT claims against the one per-Service pool.",
           "stakeholders": ["merchant", "customer"]
         },
@@ -183,6 +270,29 @@
         }
       ]
     },
+    {
+      "rule_id": "PLAN-REWARD-SCALE-01",
+      "dimension": "economics",
+      "trigger": "Review-bounty scale (T-02, bsn7-tn-261026): a per-claim bounty larger than the margin of the order that earns it makes the reputation rail a bounty-farm target — buyers (or sybil accounts) manufacture cheap orders, claim the bounty, and drain the pool; the shop pays out more per claim than the sale earns. The former template default (1000000000) was 50x a 0.02-WOW SKU and passed every audit silently. Compile now DERIVES the bounty (2% of the cheapest positive SKU, floored at 1 smallest unit); this rule judges explicit overrides and custom plans. Disclosure, not a blocker: a deliberate loss-leader bounty is a legal promotion.",
+      "cases": [
+        {
+          "when": { "field": "reward_scale_breach", "op": "truthy" },
+          "level": "medium",
+          "title": "Review bounty is ${reward_scale_ratio_display} — each claimed order pays out more than the sale earns",
+          "description": "The plan mounts a per-claim bounty of ${reward_bounty_amount} (smallest units) against a cheapest SKU of ${lowest_sku_price}: every claim consumes more pool than the order brought in, and the funded pool pays ~${reward_max_claims} such claim(s) before running dry. That is the exact bounty-farm shape (T-02): cheap orders in, bounty out, pool drained.",
+          "mitigation": "Lower the reward_claim_amount input, or raise the cheapest SKU price — the compile default (2% of the cheapest positive SKU) is the sanctioned starting point; keep explicit overrides under half the cheapest SKU price unless the over-size is a deliberate, disclosed promotion.",
+          "stakeholders": ["merchant"]
+        },
+        {
+          "when": { "field": "reward_scale_unverifiable", "op": "truthy" },
+          "level": "medium",
+          "title": "Review-bounty scale cannot be judged from the plan",
+          "description": "The plan mounts a per-claim bounty of ${reward_bounty_amount}, but the sales catalog carries no parseable price here (display forms need token decimals the plan layer does not have), so the bounty-to-price ratio is DEFERRED, not skipped — stated explicitly rather than passed silently (the audit-silent gap T-02 closes).",
+          "mitigation": "Provide numeric smallest-unit sales prices so the plan layer can judge the ratio; the quote face discloses the live bounty-to-cheapest-SKU ratio at basket time regardless.",
+          "stakeholders": ["merchant"]
+        }
+      ]
+    },
     {
       "rule_id": "DUAL-RAIL-01",
       "dimension": "fund_flow",
@@ -348,6 +458,21 @@
           "stakeholders": ["merchant", "customer"]
         }
       ]
+    },
+    {
+      "rule_id": "GUARD-REACH-01",
+      "dimension": "composition",
+      "trigger": "A guard's root AND chain carries a proof-level structural contradiction: an ordering interval crossing (>= 10 conjoined with <= 5, or equal bounds with a strict side like >= X with < X), an equality family contradiction (one channel asserted == to two different numeric constants or to opposite Bool constants, or == X conjoined with > X / < X), or a same-binding self-comparison with a strict direction (X > X / X < X). The predicate is unsatisfiable by construction: the guard can never pass, and every path it gates is permanently unreachable after publish (guards freeze at creation; S3 plane static reachability). Deliberately conservative — only proof-level classes are reported: query-vs-query legs across DIFFERENT bindings (e.g. allocation.balance >= order.amount) and runtime submission values are decided at runtime and are never reported here; OR branches and negation scopes are not conjunctive and are not descended.",
+      "cases": [
+        {
+          "when": { "field": "guard_reach_contradiction_count", "op": "gt", "value": 0 },
+          "level": "critical",
+          "title": "Guard predicate is self-contradictory: ${first_guard_reach_contradiction}",
+          "description": "All contradictions: ${guard_reach_contradiction_display}. Each is a proof, not a heuristic: two legs on the same channel demand impossible bounds at the same constant, so the guard evaluates false on every submission. Any forward, allocator row or claim rail gated by it is dead on arrival — and any escrow that can only leave through that path is stranded. Guards freeze at creation, so nothing can repair the predicate after publish.",
+          "mitigation": "Repair the predicate before creation: drop the redundant leg (keep the one that states the business intent — e.g. the window lower bound OR the upper bound, never a crossing pair), or correct the constant so the legs can both hold. If one leg was meant for a DIFFERENT state, split the guard per state instead of conjoining them.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
     }
   ]
 }

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

@@ -14,6 +14,11 @@ export interface ArchetypeTemplate {
     fee_params: Record<string, number | string>;
     trust_mechanisms: string[];
     keeper_dependencies: string[];
+    keeper_duty?: {
+        when: string;
+        action: string;
+        miss_consequence: string;
+    }[];
     recommended_role: "merchant" | "supplier" | "both";
     role_rationale: string;
     differences: string[];
@@ -43,12 +48,24 @@ export interface ArchetypeTemplate {
     acceptance_mode?: "none" | "milestone" | "contest" | "bounty" | "agent";
     installment_mode?: "none" | "deposit_balance" | "milestone_n";
     affiliate_mode?: "none" | "commission";
+    logistics_mode?: "none" | "carrier" | "merchant_managed" | "courier" | "pickup_point";
     crowdfunding_mode?: "none" | "threshold" | "flexible";
 }
-export declare const BUILTIN_TEMPLATES_VERSION = 107;
+export declare const BUILTIN_TEMPLATES_VERSION = 122;
 export declare const BUILTIN_TEMPLATES: ArchetypeTemplate[];
 export declare const TEMPLATE_KEYWORDS: Record<string, string[]>;
 export declare const TEMPLATE_TAGS: Record<string, string[]>;
+export declare const DISCOVERY_VARIANT_TAGS: Record<string, string[]>;
+export declare function discoveryTagsForTemplate(id: string): string[];
+export declare const DISCOVERY_TAG_VOCABULARY: readonly string[];
+export declare const DISCOVERY_PRODUCT_REFS: readonly string[];
+export declare function isDiscoveryTag(tag: string): boolean;
 export declare function getBuiltinTemplate(id: string): ArchetypeTemplate | undefined;
 export declare function listBuiltinTemplates(): ArchetypeTemplate[];
 export declare function validateBuiltinTemplateCatalog(entries?: ArchetypeTemplate[]): void;
+export interface OnceSlotAdvisory {
+    template_id: string;
+    kind: "once_slot_254_on_reenterable" | "reenterable_rail_missing_period_key";
+    message: string;
+}
+export declare function auditTemplateOnceSlotArms(entries?: ArchetypeTemplate[]): OnceSlotAdvisory[];