@wowok/agent-mcp 3.4.4 → 3.4.5

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

@@ -44,6 +44,10 @@
     "first_pinned_away_exit_node": "First non-terminal machine node whose EVERY outgoing edge is guard-pinned to OTHER nodes — exhaust every exit guard and no edge can fire while the order rests here, so a never-ruling arb case strands the escrow at a mid-flow node (W5-02, ddmc4 B-29: dismissed fails closed on a None indemnity and withdraw/reset leave both ruling roots silent; NODE-MATCH-01 reports each dead edge, this is the node-level rollup; a node with NO edge at all is a terminal — its coverage stays FUND-EXIT-01/02, entry stranding stays ENTRY-ABANDON-01) (FUND-EXIT-COMPLETENESS-01)",
     "direction_blind_pay_edge_count": "Fund-track pay rows (refund / settle / recover) whose guard carries NO beneficiary-anchoring leg: no progress node pin, no machine-edge binding, no dispute freeze leg (query 1576), and no order identity leg (order.owner / order.agent has / order.service)",
     "first_direction_blind_pay_edge": "First such direction-blind pay row — the payee is fixed by the row shape alone, indifferent to order state and identity, so the residual principal sweeps merchant-ward even when the buyer WON the award (ktt4 RT-01) and an outsider can drive the rail (W5-01 b: h1w9 F-01/F-04/F-09, ddmc4 B-26/B-27, pdd F-01/F-05, tbpr7 F-V3-01/16, ks7 F-21) (FUND-DIRECTION-BLIND-01)",
+    "state_pinned_identity_blind_pay_edge_count": "Fund-track pay rows whose guard anchors ORDER STATE only (progress node pin / machine-edge binding / dispute freeze) with NO order identity leg (order.owner / order.agent has / order.service) — driver-blind within the pinned state: the machine dispatch authenticates the resting node, never the caller, so any address may fire the rail while the order rests there (ctr9 F-T17 / beatstars T11) (RAIL-DRIVER-BLIND-01, medium advisory; W5-01 b ruling intact)",
+    "first_state_pinned_identity_blind_pay_edge": "First such state-pinned-only rail, rendered as: <track> row on guard '<key>' (<step>) — state-pinned only (<mechanism>); no order identity leg — any address may drive the rail while the order rests in the pinned state",
+    "arb_gated_money_row_count": "Money rows whose guard reads arbitration state (order.claimed_by / arb queries) — their ratio split is AWARD-INDEPENDENT (decision 11: the two tracks are decoupled on chain), so the row's guard legs and description are the only statement of where the principal goes when the buyer WINS the award (ddmc3 F-D3-05) (ARB-PAIRING-DISCLOSURE-01, info — decision 11 intact)",
+    "first_arb_gated_money_row": "First such arbitration-gated money row — carry this line into the quote/mandatory disclosure face verbatim: on a buyer-won award the principal's destination follows this row's guard legs and description; the arbitration ruling does not change the split ratios",
     "first_refund_guard_missing_claimed_by": "First refund-track guard step id whose queries never read order.claimed_by (DUAL-RAIL-01, A-3)",
     "first_path_dependent_anchor": "First guard step id using a path-dependent time query (TIME-ANCHOR-01, E-10)",
     "path_sensitive": "The anchored node is reachable by more than one path, so the anchor can shift",
@@ -89,6 +93,8 @@
     "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)",
+    "entry_payer_strand_nodes": "Comma-joined entry landing nodes whose EVERY exit forward rides the order-holder rail (namedOperator \"\") with no permission/keeper rail — the kernel defaults entry edges to the buyer rail, so a buyer who pays and never signs pins Progress there forever and the entry escrow locks with no clock even involved (ENTRY-ABANDON-01 case ③, upw-mn-261110 P0-1)",
+    "entry_payer_strand_count": "How many entry landing nodes are buyer-signature-only (ENTRY-ABANDON-01 case ③ judgment gate)",
     "window_strand_nodes": "Comma-joined NON-ENTRY rest nodes whose EVERY exit is gated by a CLOSING time window (Clock <= anchor, no opening leg, no unguarded alternative) — once the window elapses the order cannot advance and the escrow held at that rest state has no firing rail (ENTRY-ABANDON-01 case ②, ctrx-mn-261108 O14/O15/O19: 1.10 WOW stranded after a claim_window's only exits closed)",
     "window_strand_count": "How many non-entry rest nodes are window-stranded (ENTRY-ABANDON-01 case ② 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)",
@@ -145,18 +151,21 @@
     "guard_find_polarity_count": "Total find:\"first\" periodic-node anchors across the plan's guards",
     "guard_find_polarity_per_period": "At least one such anchor's description claims PER-PERIOD semantics the find:\"first\" polarity cannot deliver — the critical face of the family",
     "guard_find_polarity_display": "Semicolon-joined list of ALL periodic-anchor guards, each rendered with its own guard id, target node, and per-period verdict",
+    "reward_anchor_conflict_count": "Consumer guards (Reward claim guards + repository policy write guards) mounted as the edge guard of a forward LEAVING a node the guard anchors (REWARD-ANCHOR-CONFLICT, mtw-mn-261109 MN-29 / amz-mn-261109 F-16 sibling)",
+    "first_reward_anchor_conflict": "First anchor-consuming mount, rendered as: guard 'id' anchors progress.current == 'node' yet also drives the forward prev -> next — the forward consumes the guard's own anchor",
+    "reward_anchor_conflict_display": "Semicolon-joined list of ALL anchor-consuming mounts",
+    "unguarded_rail_count": "Machine edges carrying NO guard mount (MACHINE-PUBLISH RAIL FACE, mtw-mn-261109 MN-13). The kernel still gates them behind the operator permission rail (default merchant 1000) — disclosed, not open",
+    "first_unguarded_rail": "First unguarded edge, rendered as prev -> next (forward names)",
+    "unguarded_rail_display": "Semicolon-joined list of ALL unguarded edges",
+    "nodeless_reused_guard_count": "One guard mounted on ≥2 machine edges with NO progress.node accepted-leg (GUARD-BINDING-SCOPE, amz-mn-261109 F-13/F-16 sibling) — it fires in every node context its other legs allow",
+    "first_nodeless_reused_guard": "First node-less reused mount, rendered with the guard id and its edge list",
+    "nodeless_reused_guard_display": "Semicolon-joined list of ALL node-less reused mounts",
+    "plan_hand_built": "Present ONLY when the plan carries no templateId — the hand-built provenance marker that scopes MACHINE-PUBLISH-RAIL-FACE (template plans carry their reviewed rail design)",
     "refund_convergence_missing": "The plan ships a refund-track allocator row but NO machine edge into closed_refunded is gated by order.principal_refunded (chain-query 1579, the RefundStamp latch) — the refund loop has no provable close (R-REFUND-CONVERGENCE, K3 C3). CHAIN-TRUTH CORRECTION (upw-b7k2 R3, 2026-11-09): the O-F22 zombie-order shield (progress.move:600) aborts EVERY order-scoped advance/hold AFTER the principal is fully refunded, and the abort fires BEFORE guard evaluation (progress.move:634/672) — so this convergence edge can NEVER fire: full refund latches the guard's own precondition but the advance aborts first; partial refund leaves the latch false. The latch QUERY itself (1579) is the refund loop's real close proof; the edge is bookkeeping-dead pending the kernel whitelist proposal (see PG-ZOMBIE-01). Do not treat reaching closed_refunded as a live path",
-    "withdraw_no_case_bind_count": "WithdrawClaim machine edges whose bound guards read NO order.dispute.open leg (chain-query 1576) — a withdrawal with no case binding: replay farming (file->withdraw cycles need no new on-file dispute) and phantom/foreign cases satisfy nothing but also block nothing (R-WITHDRAW-NO-CASE-BIND, PT-26/ssng6)",
-    "first_withdraw_no_case_bind": "First such unbound withdraw edge, rendered as prev->next",
-    "withdraw_no_case_bind_display": "Semicolon-joined list of ALL unbound withdraw edges",
+    "dispute_withdraw_edge_count": "Machine edges whose forward name matches /withdraw/i AND /claim|dispute/i on the SAME name (the WithdrawClaim/WithdrawClaimReturn withdrawal-of-a-filed-claim family). D2 no-withdraw doctrine (2026-11-10): a filed arbitration claim cannot be withdrawn anywhere on WOWOK — DISPUTE-WITHDRAW-BANNED (critical)",
+    "dispute_withdraw_edges": "Semicolon-joined list of ALL dispute-withdraw edges, rendered as prev->next",
     "settlement_triggers_display": "Semicolon-joined per-settlement-rail caller-identity faces: each rail's bound guard identity legs (order.owner==signer / order.agent has signer / order.service binding / permission role), or the kernel edge-rail default when the guard carries no caller face — the 'who can trigger settlement' disclosure (K3 C4)",
-    "settlement_buyer_only_count": "Settlement rails whose ONLY caller face is the order-holder leg (order.owner/order.agent) with no service-binding or permission-role face — the buyer triggers the merchant's settlement (role-reversal advisory, SETTLEMENT-TRIGGER-SCOPE)",
-    "dispute_freeze_rail_count": "Machine edges OTHER than withdraw edges whose bound guards read order.dispute.open (chain-query 1576) — dispute-freeze money rails gated on the open-dispute state (R-DISPUTE-EXIT-REACHABILITY, ss10 F-SS10-01)",
-    "dispute_freeze_rail_display": "Semicolon-joined list of ALL dispute-freeze rail edges, rendered as prev->next",
-    "dispute_exit_live_withdraw_count": "Withdraw-class edges whose guards read order.dispute.open (case-bound) but carry NO order.claimed_by disposition precondition — taking the edge leaves the case live forever (dispute vector is push-only, claimed_by has no clearer), freezing every dispute-freeze rail (ss10 F-SS10-01)",
-    "dispute_exit_live_withdraw_display": "Semicolon-joined list of ALL live-withdraw edges, rendered as prev->next",
-    "dispute_exit_dead_topology": "Flag: freeze rails + live withdraw edges coexist AND the machine exposes NO conclude/compensate-class forward — NOTHING can stamp claimed_by, the frozen rails are unreachable, escrow locks with no recovery path (high)",
-    "dispute_exit_indirect_stamp": "Flag: freeze rails + live withdraw edges coexist AND a conclude/compensate-class forward exists — recovery only via a FULL fresh arbitration cycle filed after the withdraw (medium disclosure)"
+    "settlement_buyer_only_count": "Settlement rails whose ONLY caller face is the order-holder leg (order.owner/order.agent) with no service-binding or permission-role face — the buyer triggers the merchant's settlement (role-reversal advisory, SETTLEMENT-TRIGGER-SCOPE)"
   },
   "rules": [
     {
@@ -264,7 +273,7 @@
           "level": "critical",
           "title": "Every exit of '${first_pinned_away_exit_node}' is guard-pinned to other nodes — the order strands here",
           "description": "While the order rests at '${first_pinned_away_exit_node}', none of its outgoing edges can fire: every edge guard pins progress.current to a DIFFERENT node (NODE-MATCH-01 already reports each such edge; this is the node-level rollup — exhaust every exit guard, find no live exit). The order and its escrow are unreachable-by-construction from here on (W5-02, ddmc4 B-29 D6: the never-ruling arb case — tpl_forward_arb_ruling_won needs a positive award and dismissed fails closed on a None indemnity, so withdraw/reset leave BOTH ruling roots silent and an arb waypoint gated only by rulings is this same deadlock expressed through guard pins; ETSY-T1 catalog deadEndLock is the catalog-level twin). Exit coverage is evaluated ONLY on fund-exit grounds (R2-01 lesson): node-level rollup, no whole-graph topology walk. A node with NO outgoing edge at all is a terminal — its coverage is FUND-EXIT-01/02's face, not this gate.",
-          "mitigation": "Re-pin the guards so at least one edge accepts the node the order actually rests on, or add an unpinned escape edge. For an arb waypoint the canonical shape is the buyer's void escape: { prev: <waypoint>, forward: 'WithdrawClaim', operator: 'order_payer', guard_key: 'withdraw_claim_<leg>' } with a pattern.identity_check_order_holder guard — no ruling means arb.claimed_by is none, the order stays put, and the FULL escrow returns through the untouched node-gated refund track (decision 11 two-rail independence). A ForceSettleExpired clock edge (buyer-directed) is the acceptable fallback; never gate the only live exit on a ruling that can fail closed. A live exit means: an edge whose guards are empty, or whose guard's acceptedNodes includes this node.",
+          "mitigation": "Re-pin the guards so at least one edge accepts the node the order actually rests on, or add an unpinned escape edge. For an arb waypoint, the D2 no-withdraw doctrine (2026-11-10) BANS the former buyer void escape ({ prev: <waypoint>, forward: 'WithdrawClaim', operator: 'order_payer' } — a filed claim cannot be withdrawn); the canonical shapes are a conclude/compensate-class ruling edge (stamps arb.claimed_by) and a ForceSettleExpired clock edge (buyer-directed); never gate the only live exit on a ruling that can fail closed. A live exit means: an edge whose guards are empty, or whose guard's acceptedNodes includes this node.",
           "stakeholders": ["merchant", "customer"]
         }
       ]
@@ -283,6 +292,34 @@
         }
       ]
     },
+    {
+      "rule_id": "RAIL-DRIVER-BLIND-01",
+      "dimension": "fund_flow",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "first_state_pinned_identity_blind_pay_edge", "op": "present" } ] },
+          "level": "medium",
+          "title": "Money rail '${first_state_pinned_identity_blind_pay_edge}' — state-pinned but driver-blind: any address can fire it in the pinned state",
+          "description": "A refund/settle/recover rail's guard anchors the ORDER STATE (node pin / edge mount / dispute freeze) but carries no order identity leg (order.owner / order.agent has / order.service). The machine dispatch authenticates the resting node, never the CALLER — so while the order rests in the pinned state, any address may drive the rail and its pay split executes (ctr9-mn-261110 F-T17 / beatstars T11: a stranger fired the recover gate, the rail swept through the recover split, and the merchant contract fee left with it). FUND-DIRECTION-BLIND-01 stays the critical gate for fully-unanchored rails (W5-01 b ruling); this advisory exposes the residual window state pins alone leave open. Medium tier per CHARTER §3.4 — new rules enter the non-blocking tier first; catalog surgery precedes any high/critical upgrade.",
+          "mitigation": "Graft one identity leg onto the rail's guard: order.service (1563 == this service) as the minimum tenant check, or order.owner (1562) / order.agent has (1567) when the driver must be a specific party — the canonical guard_refund leg-2 shape, no node literals. Keep the state pin.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "ARB-PAIRING-DISCLOSURE-01",
+      "dimension": "fund_flow",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "first_arb_gated_money_row", "op": "present" } ] },
+          "level": "info",
+          "title": "Arbitration-gated money row '${first_arb_gated_money_row}' — carry the buyer-won principal destination into the disclosure face",
+          "description": "Decision 11 (permanent): the escrow/refund track and the arbitration are decoupled on chain — a ruling never re-splits the pool's ratios. Any money row whose guard reads arbitration state (order.claimed_by / arb queries) is therefore award-INDEPENDENT: when the buyer WINS, the principal goes wherever the row's guard legs route it, not to the award winner. K3 TRIAGE-261110 ruling 1 (ddmc3 F-D3-05): \"protocol allows it\" is not \"report it as a defect\", but the MCP disclosure face MUST state where the principal goes on a buyer-won award — the row's guard legs and description are the only such statement. Info level, non-blocking, catalog-wide.",
+          "mitigation": "Carry the disclosure line verbatim into service_quote / mandatory_disclosures: on a buyer-won award the principal's destination follows this row's guard legs and description; the arbitration ruling does not change the split ratios. Template authors who intend award-following payouts must implement them as explicit paired rows (one gated on award-paid, one on award-unpaid), each with its own description.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
     {
       "rule_id": "FUND-ZERO-01",
       "dimension": "fund_flow",
@@ -326,6 +363,14 @@
           "description": "Every forward leaving '${window_strand_nodes}' is gated by a closing time window (Clock <= anchor) with no opening leg and no unguarded alternative. Those nodes are not entry nodes, but the escrow is still HELD while the order rests there — and a machine has no rail that can fire at an arbitrary node: once the last window closes nothing advances the order and no allocator row covers that state, so the money sits until the protocol changes. This is the live ctrx-mn-261108 C shape (O14/O15/O19, 1.10 WOW): a claim_window whose FileDispute/WithdrawClaim exits both aborted after the window, while the fund rails only covered completed / closed_cancel / return_closed / claim_withdrawn. Filing is deliberately unrestricted in time (arbitration.move order-anchored filing-window gate removed 2026-11-08), so a late filing can pin an otherwise settleable order — the fix must exist in the MACHINE, not in a filing clock.",
           "mitigation": "Give every such rest state at least one exit that stays walkable after its windows close — an OPENING-window fallback (Clock >= anchor), an unguarded advance, or a node-free/any-time guard — and route it to a node covered by a fund rail (or make the cover rail accept this node explicitly). A state where money rests with no after-window exit is a publish-time defect, not an operator duty.",
           "stakeholders": ["merchant", "customer"]
+        },
+        {
+          "when": { "field": "entry_payer_strand_nodes", "op": "truthy" },
+          "level": "critical",
+          "title": "Entry node(s) '${entry_payer_strand_nodes}' exit ONLY through buyer-signature forwards — an absent buyer locks the escrow at genesis",
+          "description": "Every forward leaving '${entry_payer_strand_nodes}' — where orders land at entry — rides the order-holder rail (namedOperator \"\"), so only the BUYER's signature can advance the order past it. A buyer who pays and never acts — the routine abandonment case — pins Progress at this node forever: no merchant or keeper forward exists to fire, and unlike a closing-window strand no clock is even involved (the lockup is total from the first block). The escrow taken at buy can never refund and the work can never start; Machine topology freezes at publish (IMMUT-001), so nothing can be added afterwards. This is the live upw-mn-261110 P0-1 shape: catalog-tiers' genesis state had only the buyer's requirement-submission advance, so every never-started order locked its escrow until the template shipped the keeper EntryAbandonTimeout entry pair.",
+          "mitigation": "Give the node at least one NON-buyer exit: a keeper/merchant OPENING-window timeout (Clock >= anchor on a permissionIndex rail) into a refund-covered terminal, or an unguarded merchant advance. Reuse the deadline the template already declares where possible — one unpinned, order.time-anchored Guard object may legally gate several mounts (E_DUPLICATE_NODE_PREV is per target node, so a second entry pair prev:\"\" is chain-legal).",
+          "stakeholders": ["merchant", "customer"]
         }
       ]
     },
@@ -1093,6 +1138,51 @@
         }
       ]
     },
+    {
+      "rule_id": "REWARD-ANCHOR-CONFLICT",
+      "dimension": "incentive",
+      "trigger": "A CONSUMER guard — a Reward claim guard or a repository policy write guard (the refs of the plan's reward/repository create steps) — is ALSO mounted as the edge guard of a machine forward LEAVING a node the guard anchors (acceptedProgressNodes ∩ edge.prev). Taking that forward flips progress.current and consumes the guard's own anchor: every later claim/write through the guard aborts with code 7 forever (mtw-mn-261109 MN-29; amz-mn-261109 F-16 sibling — the rating write shares the review forward's guard, so past the review window neither the review, nor the rating, nor the bounty can ever land). Claims made BEFORE the forward in the SAME tx remain legal, so this discloses at warning severity — but the gate must say it: guards freeze at publish and the conflict was discovered at claim time on mainnet.",
+      "cases": [
+        {
+          "when": { "field": "first_reward_anchor_conflict", "op": "present" },
+          "level": "medium",
+          "title": "Consumer guard consumes its own anchor via the forward it drives: ${first_reward_anchor_conflict}",
+          "description": "${reward_anchor_conflict_count} mount(s) couple a claim/write guard with the business forward it anchors. Once the forward fires, progress.current leaves the anchored node and every later claim or policy write through this guard aborts permanently (guards freeze at publish; the anchor cannot be re-pointed on a live shop). Legitimate ONLY when the claim/write is intended to precede the forward within the same transaction.",
+          "mitigation": "Split the guard: keep the forward's edge guard, and give the claim/write its own guard whose accepted-node set includes every post-forward state the claim must survive (or drop the node leg and gate on the policy/reward record). If claim-then-forward-in-one-tx is the intent, state it in the guard description and train the operator flow accordingly.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "MACHINE-PUBLISH-RAIL-FACE",
+      "dimension": "composition",
+      "trigger": "A machine edge carries NO guard mount on a HAND-BUILT plan (templateId absent — mtw-mn-261109 MN-13). The kernel still gates the edge behind the machine's operator permission rail (default merchant index 1000), so it is not world-open, but that face is invisible: every rail holder can drive cancel/refund-class edges and no finding ever said so. Template plans carry their reviewed rail design, so the finding is scoped to hand-built plans; the fact stays emitted for every plan so the panorama/quote layer can show it. This is the machine-publish counterpart of settlement_triggers (service publish) — together they close the 'who can drive this state exit' disclosure at the gate instead of at the abort.",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "first_unguarded_rail", "op": "present" }, { "field": "plan_hand_built", "op": "present" } ] },
+          "level": "info",
+          "title": "Hand-built machine edge with no guard — kernel operator rail is the only gate: ${first_unguarded_rail}",
+          "description": "${unguarded_rail_count} edge(s) carry no guard mount. Anyone holding the machine's operator permission rail (default: merchant index 1000) can fire these forwards — including cancel/refund-class exits that move state on a money-adjacent rail. Funds still move only through allocator guards, but the STATE exit is rail-gated, not guard-gated.",
+          "mitigation": "Mount an explicit guard on each listed edge (order.owner leg for buyer-initiated exits, or a permission-scoped guard for staff-initiated ones), or accept the rail face and record it in the shop's operating notes.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "GUARD-BINDING-SCOPE",
+      "dimension": "composition",
+      "trigger": "One guard is mounted on ≥2 machine edges while carrying NO progress.node accepted-leg (amz-mn-261109 F-13/F-16 sibling — the reused/custom-guard hazard the user asked the gate to catch at BIND time). A node-less guard fires in every node context its other legs allow: when the same guard object is reused across edges, one context's legs leak into the other (evidence accepted at the wrong node, windows opened at the wrong state). Single-mount node-less guards are a legitimate design (pure time/policy guards) and stay silent.",
+      "cases": [
+        {
+          "when": { "field": "first_nodeless_reused_guard", "op": "present" },
+          "level": "low",
+          "title": "Reused guard has no node scoping — one context leaks into the other: ${first_nodeless_reused_guard}",
+          "description": "${nodeless_reused_guard_count} reused mount(s) lack a progress.node leg. Guards freeze at publish; a guard meant for one node silently governs every node it is mounted on. This is the binding-time risk check for custom and reused guards: the gate now says what the runtime would have discovered by abort.",
+          "mitigation": "Give each mount its own guard copy with an explicit progress.current leg, or add the node leg to the shared guard so every context is discriminated.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
     {
       "rule_id": "R-REFUND-CONVERGENCE",
       "dimension": "fund_flow",
@@ -1108,6 +1198,21 @@
         }
       ]
     },
+    {
+      "rule_id": "R-CONVERGENCE-DRIVE-RAIL",
+      "dimension": "fund_flow",
+      "trigger": "Disclosure face (of-e2e-261109 F-16/F-17/B-08 misjudgment family): the machine carries a refund-latch convergence edge — a forward whose bound guard queries order.principal_refunded (chain-query 1579). Chain truth (progress.move:632-637 vs 686-688): the ORDER-SCOPED advance runs assert_zombie_order and aborts (code 15) once the escrow principal is fully refunded, while the GENERIC scope (`operate.scope='generic'` → next_with_passport, order=false threading) skips the shield by design and is the SANCTIONED rail for exactly this edge class (UCAT-261109 F-02, K3 CHAIN-TRUTH.md option b). The convergence rail itself is correct design — this rule exists so the drive rail is taught at publish instead of being (mis)discovered by an abort and misread as a kernel deadlock.",
+      "cases": [
+        {
+          "when": { "field": "first_convergence_rail", "op": "present" },
+          "level": "info",
+          "title": "Refund-latch convergence edge — drive it with operate.scope='generic': ${first_convergence_rail}",
+          "description": "${convergence_rail_count} convergence edge(s): ${convergence_rail_display}. These edges' guards read order.principal_refunded, so they only become satisfiable AFTER the escrow principal is fully refunded — and at that point the order-scoped advance refuses by chain design (zombie-order shield, abort 15: no fulfillment on a fully refunded order). This is NOT a deadlock: the generic scope rail drives the same forward without order threading (guard, task binding and permission still verify; no zombie check). Note the latch fires only at the FULL order amount — partial refunds never latch it, so a partially refunded order converges through the dispute/ruling rails instead.",
+          "mitigation": "Operate the listed forwards with operate.scope='generic' (the SDK progress operate accepts the scope flag). Never re-drive generic scope on FULFILLMENT edges — the shield exists to stop delivering work on a refunded order; generic scope is for convergence bookkeeping rails only. Partial refunds do not latch the 1579 stamp: route those through the dispute/arbitration close.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
     {
       "rule_id": "R-LATE-REMEDY",
       "dimension": "fund_flow",
@@ -1139,46 +1244,61 @@
       ]
     },
     {
-      "rule_id": "R-WITHDRAW-NO-CASE-BIND",
-      "dimension": "fund_flow",
-      "trigger": "A plan ships a machine edge with the WithdrawClaim forward whose bound guards read NO order.dispute.open leg (chain-query 1576, order.dispute.open — mirrors order::has_open_dispute). The compile kernel mounts the bind leg on every catalog withdraw edge (guard-fill andDisputeBindLeg, PT-26 2026-11-08); this twin judges hand-built plans and inline guard_resolutions overrides, which own their root outright.",
+      "rule_id": "DEADLINE-ENTRY-GATE",
+      "dimension": "time_semantics",
+      "trigger": "gf-e2e-7q3mzt F-R3-06 / ksk-mn-261110 ISSUE-012 (verified 2026-11-10): order::buy performs NO deadline check — every campaign close is a guard leg. A plan that declares a deadline input (campaign_deadline_ms family) while the machine ENTRY edge (prev=\"\") carries no guard lets pledges enter AFTER the close, and the deadline legs on the exit rails then strand the late entry (withdraw denied, refund rails node-mismatched).",
       "cases": [
         {
-          "when": { "field": "withdraw_no_case_bind_count", "op": "gt", "value": 0 },
-          "level": "medium",
-          "title": "WithdrawClaim edge with no case binding: ${withdraw_no_case_bind_count} withdraw edge(s) read no open-dispute leg",
-          "description": "${withdraw_no_case_bind_display}. A withdrawal whose guard carries only the identity leg (order-holder set, no dispute-state read) admits with NO case on file: the same buyer can farm file->withdraw cycles for free (each cycle re-anchors keeper clocks and perturbs the public state face), and a case on a DIFFERENT order neither helps nor blocks — the withdraw reads no arbitration object at all. The kernel mounts the case-binding leg (query 1576 must read TRUE on THIS order) automatically on catalog templates; a hand-built plan shipping without it keeps the ssng6 residuals live.",
-          "mitigation": "AND a tpl_order_has_open_dispute leg onto the withdraw edge's guard (the kernel does this for every catalog WithdrawClaim edge; the hand-built equivalent is the bare positive query order.dispute.open on the order's submission slot). Protocol gate (v139): 1576 is flag-gated (enable_order_dispute_state) — on an older binary the leg reads false and the withdraw edge goes dark (degrade polarity is INVERTED vs the settlement freeze leg, which degrades open); check upgrade_check (DEPLOY-K1).",
+          "when": { "field": "deadline_entry_unguarded", "op": "truthy" },
+          "level": "high",
+          "title": "Deadline declared but entry edge unguarded: late pledges can enter after the close (entry → ${first_entry_edge_node})",
+          "description": "The plan declares '${deadline_input_key}' yet the machine entry edge into '${first_entry_edge_node}' carries no guard. The chain's buy verb is Clock-blind — only guard legs close a campaign. Pledges entering after the deadline hit the deadline legs on the withdraw/refund rails and strand: the late entry has no exit (gf o8-late: bought post-deadline → withdraw denied → funds stuck; ksk: deadline passed 18 minutes before Enter was still accepted).",
+          "mitigation": "Bind a time-window guard on the entry edge before publish: template_guard 'tpl_time_window_upper_absolute' with value_key '${deadline_input_key}' (Clock <= deadline), the same absolute instant the exit rails already read — machine topology freezes permanently at publish (IMMUT-002). If the business intends an open-ended intake, drop the deadline input instead of leaving the pair divergent.",
           "stakeholders": ["merchant", "customer"]
         }
       ]
     },
     {
-      "rule_id": "R-DISPUTE-EXIT-REACHABILITY",
-      "dimension": "fund_flow",
-      "trigger": "Cross-EDGE state reachability (ss10 F-SS10-01, 2026-11-09): the plan ships BOTH a dispute-freeze money rail (a guard reading order.dispute.open on a NON-withdraw edge) AND a withdraw edge whose guards read order.dispute.open (case-bound) but carry NO order.claimed_by disposition precondition. Each shape is correct alone; the composition locks escrow: order::dispute() is push-only and claimed_by has no clearer, so a file->withdraw cycle leaves has_open_dispute TRUE forever and every freeze rail is unreachable from the withdrawn state.",
+      "rule_id": "ENTRY-DEADLINE-SYNC",
+      "dimension": "time_semantics",
+      "trigger": "VFY-5 (ktt T2, verified 2026-11-11): order::buy is Clock-blind and never reads the machine graph, so an ENTRY edge gated by an ABSOLUTE closing window (Clock <= identifier resolving to an epoch instant; per-order anchors — order.time / progress.current_time / progress.session.forward.time — are exempt because no order exists at buy time) protects escrow only when the Service buy_guard enforces the SAME instant at buy time. Without the sync leg a buyer buys after the close, the entry deadline then rejects every forward, and the escrow strands at the entry node (keeper refund rail only).",
       "cases": [
         {
-          "when": { "field": "dispute_exit_dead_topology", "op": "gte", "value": 1 },
+          "when": { "field": "entry_deadline_buy_desync", "op": "truthy" },
+          "level": "critical",
+          "title": "Entry deadline without a synced buy gate: purchases stay open past the close (entry → ${entry_deadline_node})",
+          "description": "The machine entry edge into '${entry_deadline_node}' (guard ${entry_deadline_guard}) closes on the absolute instant ${entry_deadline_value}, but the buy face does not read it (${buy_guard_deadline_state}). A purchase after the close succeeds, then every forward off the entry node is rejected by the deadline leg — the escrow can only leave through the keeper refund rail (ktt T2: a coupon order bought post-deadline locked its escrow at the entry node).",
+          "mitigation": "Sync the pair BEFORE publish: mount the same closing window (Clock <= ${entry_deadline_value}) on the Service buy_guard — template_guard 'tpl_time_window_upper_absolute_ms' reading the shared deadline value/key — so the buy is refused once the entry edge is dead. If the intake is meant to stay open, drop the entry deadline instead of leaving the pair divergent. Machine topology freezes at publish (IMMUT-002) and the buy_guard slot freezes with the service.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "TIME-WINDOW-CLOSED-AT-BIRTH",
+      "dimension": "time_semantics",
+      "trigger": "K3 round-2 (2026-11-10), found while curing the deadline-entry gate: a closing window (kernel form logic_as_u256_lesser_or_equal[Clock, identifier]) whose identifier resolves to 0 evaluates to `Clock <= 0` — shut since genesis. The plan SHAPE is healthy (the guard is mounted on the right edge with the right root), so shape-level gates pass and the defect only shows at runtime as 'this rail can never fire' / 'the service cannot be ordered at all'. Typical cause: a deadline input that was never derived (campaign/build clock absent) leaving the 0 sentinel in the identifier table.",
+      "cases": [
+        {
+          "when": { "field": "time_window_closed_at_birth", "op": "truthy" },
           "level": "high",
-          "title": "Dispute-exit dead topology: ${dispute_exit_live_withdraw_count} withdraw edge(s) strand ${dispute_freeze_rail_count} dispute-frozen rail(s) with NO recovery path",
-          "description": "Freeze rail(s): ${dispute_freeze_rail_display}. Live withdraw edge(s): ${dispute_exit_live_withdraw_display}. Chain truth (order.move): dispute() only pushes (no removal verb), claimed_by is stamped ONLY by compensate()/conclude(), and has_open_dispute() = dispute non-empty && claimed_by none. A buyer who files a dispute and takes the withdraw edge leaves the case live forever; this machine exposes NO conclude/compensate forward, so NOTHING can ever turn has_open_dispute false — the frozen rails (refunds gated on NOT dispute.open) are unreachable and the escrow locks (ss10 mainnet: 0.20 WOW permanently locked exactly here).",
-          "mitigation": "Wire a disposition path: a conclude/compensate-class forward reachable from the withdrawn node (the arb case_conclude rail stamps claimed_by), or add a claimed_by disposition precondition leg to the withdraw edge so withdrawal is only possible AFTER the case was stamped. Root cure is protocol-train PT-26 Plan C (order::withdraw_dispute clearing verb) — register, do not hand-patch.",
+          "title": "Closing window anchored at 0: '${closed_window_node}' can never fire (guard ${closed_window_guard})",
+          "description": "The guard '${closed_window_guard}' on the edge into '${closed_window_node}' compares Clock against an identifier whose value is 0, so the window is closed from genesis. Every forward behind it is permanently unreachable — for an entry edge this means the service cannot be ordered at all; on an exit rail it means the money can never leave through that path. Shape-level gates do not catch this: the guard is mounted correctly, only its VALUE is unusable.",
+          "mitigation": "Make the window anchor derivable before publish: supply the deadline input (campaign_deadline_ms family) or the build clock/duration the template derives it from, then re-generate. If the business genuinely wants an open-ended window, remove the time-window guard instead of shipping one anchored at 0 — a mounted-but-dead guard silently blocks the whole rail.",
           "stakeholders": ["merchant", "customer"]
         }
       ]
     },
     {
-      "rule_id": "R-DISPUTE-EXIT-INDIRECT-STAMP",
+      "rule_id": "DISPUTE-WITHDRAW-BANNED",
       "dimension": "fund_flow",
-      "trigger": "Same coexistence as R-DISPUTE-EXIT-REACHABILITY, but the machine DOES expose a conclude/compensate-class forward — recovery exists only through a FULL re-arbitration cycle filed AFTER the withdraw (no dispute removal verb means the withdrawn case keeps has_open_dispute TRUE until some case stamps claimed_by).",
+      "trigger": "D2 no-withdraw doctrine (user ruling 2026-11-10): WOWOK does not support withdrawing a filed arbitration claim, anywhere. Once a dispute is filed, no withdrawal path may exist in any template or hand-built plan, and the arbitration fee is NON-REFUNDABLE. Chain truth: order.move's withdraw-family verbs move only the Progress node — they never clear order.dispute and never write claimed_by (only conclude/compensate stamp it), so a withdrawal PERMANENTLY freezes every dispute-gated refund rail on the order. This rule supersedes the former R-WITHDRAW-NO-CASE-BIND / R-DISPUTE-EXIT-REACHABILITY / R-DISPUTE-EXIT-INDIRECT-STAMP advisories (the kernel's andDisputeBindLeg auto-mount and the PT-26 case-bind doctrine are retired with them).",
       "cases": [
         {
-          "when": { "field": "dispute_exit_indirect_stamp", "op": "gte", "value": 1 },
-          "level": "medium",
-          "title": "Dispute exit is indirect: ${dispute_exit_live_withdraw_count} withdraw edge(s) leave the case live; recovery only via a fresh arbitration cycle",
-          "description": "Freeze rail(s): ${dispute_freeze_rail_display}. Live withdraw edge(s): ${dispute_exit_live_withdraw_display}. After a file->withdraw cycle the withdrawn case stays open forever (push-only dispute vector, no clearing verb); the conclude/compensate forward on this machine can stamp claimed_by only when a NEW dispute is filed and driven to a stamped ruling. Disclose in the service terms: a withdrawn dispute freezes every dispute-gated refund until a fresh case reaches compensate/conclude — buyers perceive 'I withdrew, why is my refund blocked'. Root cure stays protocol-train PT-26 Plan C (order::withdraw_dispute).",
-          "mitigation": "Disclose the two-step recovery in build_note/quote terms, or add the claimed_by disposition precondition leg to the withdraw edge so withdrawal requires a stamped (resolved) case up front.",
+          "when": { "field": "dispute_withdraw_edge_count", "op": "gt", "value": 0 },
+          "level": "critical",
+          "title": "Dispute withdrawal is banned: ${dispute_withdraw_edge_count} dispute-withdraw edge(s) — a filed claim cannot be withdrawn",
+          "description": "Dispute-withdraw edge(s): ${dispute_withdraw_edges}. A filed arbitration claim CANNOT be withdrawn on WOWOK: the withdrawal moves only the Progress node, never clears order.dispute, and permanently freezes the order's dispute-gated refund rails. Remove the withdrawal edge and route the dispute to a ruling (conclude/compensate) instead. Filed claims cannot be withdrawn; the arbitration fee is non-refundable.",
+          "mitigation": "Delete the WithdrawClaim/WithdrawClaimReturn-family edge (any forward whose name matches /withdraw/i AND /claim|dispute/i on the same name) and its withdraw_claim guard binding BEFORE publish — machine topology freezes permanently (IMMUT-002). Route the dispute waypoint to the ruling rails (ArbRefund / ResumeAfterDismissal / conclude / compensate) as the only exits.",
           "stakeholders": ["merchant", "customer"]
         }
       ]

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

@@ -0,0 +1 @@
+63ff024f74e0e2b9daec6d4d8e2723c1eb12533043c9b82036d00a8b4b2abd5e

package/dist/knowledge/baselines/rules/progress.json.good.sha256

@@ -0,0 +1 @@
+0c053b0e17e52d6b796fc233bc3b8d412aba4abdaca052802ffd8fc83caad039

package/dist/knowledge/baselines/rules/proof.json.good.sha256

@@ -0,0 +1 @@
+754bed1bdd9bfa4460f278b7ab55397d6ca3c9ee2d4e3f66909d095e0bfab371

package/dist/knowledge/baselines/rules/registrar.json.good.sha256

@@ -0,0 +1 @@
+aa2a28971a6b4ea0eb23aac29cce8a02b78e843180cedb87c86eda7279546197

package/dist/knowledge/baselines/rules/repository.json.good.sha256

@@ -0,0 +1 @@
+36ee444b764ea29e81b6aa6a4f5fc322079c0c034ea381b13f9d86971bb4cecb

package/dist/knowledge/baselines/rules/resource.json.good.sha256

@@ -0,0 +1 @@
+283dfd6687bfbb5add354b6ff78bf1dab5a93cf4e251b1840336610f1f0707cb

package/dist/knowledge/baselines/rules/reward.json.good.sha256

@@ -0,0 +1 @@
+fd9b942daf8ed1b94e42decb7a9cec7bf097bcf1784fefd3a5e72ed2b54a3765

package/dist/knowledge/baselines/rules/service.json.good.sha256

@@ -0,0 +1 @@
+fd076383bfb53f6f9f0e369cafcc8a8570f0e2f76ffa34767b567ec39b9ef191

package/dist/knowledge/baselines/rules/treasury.json.good.sha256

@@ -0,0 +1 @@
+4d8892a430fcaf9263553702be25ee0cf130bb15ea07fb889fe5b94995bc38b9

package/dist/knowledge/baselines/rules/util.json.good.sha256

@@ -0,0 +1 @@
+fe02ed5def08fa23abfba9f018ad5b3cdc89fd4c3c21cbcb59504d576b60d063

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

@@ -71,7 +71,7 @@ export interface ArchetypeTemplate {
     logistics_mode?: "none" | "carrier" | "merchant_managed" | "courier" | "pickup_point";
     crowdfunding_mode?: "none" | "threshold" | "flexible";
 }
-export declare const BUILTIN_TEMPLATES_VERSION = 213;
+export declare const BUILTIN_TEMPLATES_VERSION = 224;
 export declare const BUILTIN_TEMPLATES: ArchetypeTemplate[];
 export declare const TEMPLATE_KEYWORDS: Record<string, string[]>;
 export declare const TEMPLATE_TAGS: Record<string, string[]>;