@wowok/agent-mcp 3.3.1 → 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

@@ -1,5 +1,5 @@
 {
-  "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.",
+  "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, upwc-cat-261017 CAT-A1): zero allocator rows passing silently, an unsellable sales-less catalog, 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",
@@ -27,6 +27,13 @@
     "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)",
+    "prose_window_promise_count": "Window-context duration declarations found in the service/sales prose (PROMISE-TIME judgment gate — absent when the prose carries none)",
+    "first_prose_time_mismatch": "First prose window promise that no guard duration constant in the plan backs (PROMISE-TIME critical, upwk-mn-261017 F-55)",
+    "prose_time_mismatch_count": "Total prose window promises with no matching enforced guard duration",
+    "prose_time_mismatch_display": "Semicolon-joined list of ALL mismatched prose window promises",
+    "enforced_window_ms_display": "Comma-joined enforced window durations parsed from the plan's guard tables (plausible ms U64 constants)",
+    "first_unanchored_window_promise": "First restart/renew-style window promise, which needs an entry-anchored (1280 next_node) window guard to be true (PROMISE-TIME medium tier, F-55)",
+    "unanchored_window_promise_count": "Total restart/renew-style window promises in the prose",
     "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)",
@@ -35,9 +42,25 @@
     "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"
+    "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)"
   },
   "rules": [
+    {
+      "rule_id": "PLAN-SALES-01",
+      "dimension": "composition",
+      "trigger": "A service plan materializes zero sellable SKUs. The compile kernel emits the service_sales configure step ONLY when inputs.sales is non-empty, so a plan that reaches publish without one ships a Service frozen with sales: [] and EVERY order_new aborts on the empty catalog (upwc-cat-261017 CAT-A1: the published shop was unsellable until SKUs were hand-added, and hand-added steps bypass the plan audit entirely).",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "has_service", "op": "truthy" }, { "field": "sales_step_present", "op": "falsy" } ] },
+          "level": "high",
+          "title": "Service plan carries no sellable SKU (sales stays empty)",
+          "description": "The plan creates a Service but no step adds a sales entry, so the published object freezes with sales: []. Every order_new aborts on the empty catalog — the shop cannot take a single order, and patching the catalog by hand after publish bypasses this audit (the hand-built replica class that silently drops steps).",
+          "mitigation": "Pass a non-empty inputs.sales catalog so the compile kernel emits the service_sales configure step, keeping the catalog inside the audited plan before publish.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
     {
       "rule_id": "PLAN-ALLOC-01",
       "dimension": "fund_flow",
@@ -114,6 +137,29 @@
         }
       ]
     },
+    {
+      "rule_id": "PROMISE-TIME",
+      "dimension": "time_anchor",
+      "trigger": "The listing prose (service description / sales item text) promises a review/acceptance/cancel/refund/return/claim WINDOW that no guard-table duration in the plan enforces (upwk-mn-261017 F-55: the WIP listing promised window durations no guard carried). Both sides freeze at publish — guards are immutable and the prose ships as-is — so a mismatched promise is the declared-but-not-enforced class and is unrepairable post-publish. Shipping/delivery SLAs are deliberately OUT of scope: they are off-chain fulfillment promises no time guard is expected to enforce.",
+      "cases": [
+        {
+          "when": { "field": "first_prose_time_mismatch", "op": "present" },
+          "level": "critical",
+          "title": "Listing promises '${first_prose_time_mismatch}' but no guard enforces it",
+          "description": "Window promises found in the listing prose: ${prose_window_promise_count}; mismatched: ${prose_time_mismatch_display}. Windows the plan's guards actually enforce: ${enforced_window_ms_display}. The unenforced promise is a buyer-side remedy that dies on contact with the chain: the buyer relies on it, no guard carries it, and both the guard tables and the machine freeze at publish. Blocking.",
+          "mitigation": "Align the two sides BEFORE publish: reword the listing to match an enforced window, or add/retime a window guard (pattern.deadline_window for act-until windows, pattern.time_lock_progress for act-after windows) so a guard constant carries exactly the promised duration (fee-param-derived, e.g. review_window_days / escrow_release_days).",
+          "stakeholders": ["merchant", "customer"]
+        },
+        {
+          "when": { "field": "first_unanchored_window_promise", "op": "present" },
+          "level": "medium",
+          "title": "Window-restart promise ('${first_unanchored_window_promise}') needs an entry-anchored guard",
+          "description": "${unanchored_window_promise_count} restart/renew-style window promise(s) in the prose. A window can only restart when its guard anchors on the progress.history.time (id 1280) ENTRY timestamp of the re-open event (next_node form) — a fresh entry appends and the window re-measures. A one-shot anchor (order.time, or the current_time that is rewritten at every migration) never restarts, so the promise would be false the first time the triggering event repeats. Disclosure: confirm the anchor form before publish.",
+          "mitigation": "Anchor the window guard on progress.history.time (id 1280, next_node='<the restarting event>', find=last) so each re-entry resets the window, or reword the prose. See the time_anchors table of the archetype in use for the canonical anchor wording.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
     {
       "rule_id": "PLAN-K2",
       "dimension": "fund_flow",
@@ -208,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"]
         }
       ]
@@ -257,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/baselines/rules/reward.json

@@ -297,7 +297,7 @@
           "title": "claim on Reward with zero balance",
           "description": "Reward balance is 0. Any claim will abort with E_INSUFFICIENT_BALANCE (6). Owner must coin_add (153) or receive (154) to replenish.",
           "scenario": "Marketing campaign budget exhausted but guards remain active",
-          "mitigation": "1) Owner: coin_add to replenish. 2) Owner: guard_remove_expired + lock guard additions via the time-lock to deactivate. 3) Claimer: wait for replenishment.",
+          "mitigation": "1) Owner: coin_add to replenish. 2) Owner: guard_remove ('expired' sweep or the guard ID) + lock guard additions via the time-lock to deactivate. 3) Claimer: wait for replenishment.",
           "evidence": "balance=0",
           "stakeholders": ["claimer", "owner"]
         }

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

@@ -19,6 +19,8 @@ export interface ArchetypeTemplate {
     differences: string[];
     user_inputs: string[];
     key_risk: string;
+    compensation_fund_policy?: "allowed" | "forbidden";
+    reentry_kind?: "none" | "review-loop" | "paid-cycle";
     build_notes: string[];
     evidence_refs?: string[];
     payment_model?: "milestone" | "subscription" | "escrow";
@@ -37,10 +39,16 @@ export interface ArchetypeTemplate {
         max_total_per_recipient?: string;
     };
     review_mode?: "none" | "review" | "review_reward";
+    after_sales_mode?: "none" | "return" | "exchange" | "warranty";
+    acceptance_mode?: "none" | "milestone" | "contest" | "bounty" | "agent";
+    installment_mode?: "none" | "deposit_balance" | "milestone_n";
+    affiliate_mode?: "none" | "commission";
+    crowdfunding_mode?: "none" | "threshold" | "flexible";
 }
-export declare const BUILTIN_TEMPLATES_VERSION = 77;
+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[]>;
 export declare function getBuiltinTemplate(id: string): ArchetypeTemplate | undefined;
 export declare function listBuiltinTemplates(): ArchetypeTemplate[];
 export declare function validateBuiltinTemplateCatalog(entries?: ArchetypeTemplate[]): void;