@wowok/agent-mcp 3.1.6 → 3.2.0

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

@@ -12,6 +12,15 @@
     "rate_rule_pure": "Pure Rate mode (no Surplus) with sum > 0 and sum != RATE_TOTAL_FULL.",
     "rate_rule_exceed": "Rate + Surplus mode with rate sum > RATE_TOTAL_FULL.",
     "rate_total_full": "KERNEL CONSTANT — full rate denominator (RATE_TOTAL_FULL = 10000).",
+    "rate_gross_branch": "First pure-RateGross allocator (no NET Rate) whose gross plan cannot be paid: 'sum_exceeds_10000' | 'cap_fit' | 'fixed_full' (undefined when none).",
+    "rate_gross_index": "Allocator index of the RateGross-rule offender.",
+    "rate_gross_guard": "Guard address of the RateGross-rule offender.",
+    "rate_gross_sum": "Sum of RateGross-mode sharing values (Number()) for the offender.",
+    "rate_gross_fix": "Fixed Amount total (fix) of the RateGross-rule offender.",
+    "rate_gross_max": "Number(allocator.max) for the offender (only set on the cap_fit branch).",
+    "mixed_rate_bases_present": "An allocator mixes NET Rate and RateGross entries while carrying a fixed Amount total (fix > 0) — rejected on-chain with EMIXED_RATE_BASES (17). With fix == 0 the two rate bases coincide and mixing is allowed, so no offender is reported.",
+    "mixed_rate_bases_index": "Allocator index of the mixed-rate-bases offender.",
+    "mixed_rate_bases_guard": "Guard address of the mixed-rate-bases offender.",
     "amount_rule_branch": "First amount-rule violation branch for the first offending allocator: 'multiple_surplus' | 'below_threshold' | 'exceeds_max' (undefined when none).",
     "amount_rule_index": "Allocator index of the amount-rule offender.",
     "amount_rule_guard": "Guard address of the amount-rule offender.",
@@ -103,7 +112,7 @@
     {
       "rule_id": "R-A-1-02",
       "dimension": "structural",
-      "trigger": "Pure Rate mode sum != 10000 or Rate+Surplus sum > 10000",
+      "trigger": "Pure NET Rate sum != 10000, NET Rate+Surplus sum > 10000, a RateGross plan that cannot be paid, or NET Rate mixed with RateGross under a fixed total",
       "cases": [
         {
           "when": { "field": "rate_rule_pure", "op": "eq", "value": true },
@@ -131,6 +140,46 @@
           "mitigation": "Reduce sum(rates) to ≤ ${rate_total_full}.",
           "evidence": "rateSum=${rate_rule_sum}, max=${rate_total_full}",
           "stakeholders": ["owner"]
+        },
+        {
+          "when": { "field": "rate_gross_branch", "op": "eq", "value": "sum_exceeds_10000" },
+          "level": "high",
+          "title": "RateGross sum ${rate_gross_sum} > ${rate_total_full}",
+          "description": "Allocator ${rate_gross_index} (guard=${rate_gross_guard}) uses RateGross mode off the full pool, but sum(rates)=${rate_gross_sum} > ${rate_total_full}. Move will abort with ERATE_EXCEEDS_10000.",
+          "scenario": "RateGross percentages exceed 100% of the full pool",
+          "mitigation": "Reduce sum(RateGross rates) to ≤ ${rate_total_full}.",
+          "evidence": "grossRateSum=${rate_gross_sum}, max=${rate_total_full}",
+          "stakeholders": ["owner"]
+        },
+        {
+          "when": { "field": "rate_gross_branch", "op": "eq", "value": "cap_fit" },
+          "level": "high",
+          "title": "RateGross plan does not fit the max cap ${rate_gross_max}",
+          "description": "Allocator ${rate_gross_index} (guard=${rate_gross_guard}) uses RateGross mode with `max` set, but the plan overdraws the cap: fix×10000 + sum(rates)×max = ${rate_gross_fix}×10000 + ${rate_gross_sum}×${rate_gross_max} > ${rate_gross_max}×10000. Move will abort with ERATE_EXCEEDS_10000.",
+          "scenario": "Fixed Amount total plus gross rates overdraw the max cap",
+          "mitigation": "Lower the fixed Amount total, lower sum(RateGross rates), or raise `max` so fix×10000 + sum(rates)×max ≤ max×10000.",
+          "evidence": "fix=${rate_gross_fix}, rateSum=${rate_gross_sum}, max=${rate_gross_max}",
+          "stakeholders": ["owner"]
+        },
+        {
+          "when": { "field": "rate_gross_branch", "op": "eq", "value": "fixed_full" },
+          "level": "high",
+          "title": "RateGross sum ${rate_gross_sum} leaves no room for the fixed total",
+          "description": "Allocator ${rate_gross_index} (guard=${rate_gross_guard}) uses RateGross mode with a fixed Amount total (fix=${rate_gross_fix}) and no `max`: sum(rates)=${rate_gross_sum} ≥ ${rate_total_full} can never be paid on top of the fixed total. Move will abort with ERATE_EXCEEDS_10000.",
+          "scenario": "Gross rates at 100% plus a fixed Amount total with no cap",
+          "mitigation": "Reduce sum(RateGross rates) below ${rate_total_full}, or set a `max` cap that fits fix + rates×max.",
+          "evidence": "fix=${rate_gross_fix}, rateSum=${rate_gross_sum}",
+          "stakeholders": ["owner"]
+        },
+        {
+          "when": { "field": "mixed_rate_bases_present", "op": "eq", "value": true },
+          "level": "high",
+          "title": "Allocator ${mixed_rate_bases_index} mixes NET Rate and RateGross with a fixed total",
+          "description": "Allocator ${mixed_rate_bases_index} (guard=${mixed_rate_bases_guard}) carries both NET Rate and RateGross entries while also carrying a fixed Amount total. The two modes are measured against different rate bases (pool minus fix vs the full pool / max cap), so the sharing semantics are ambiguous. Move will abort with EMIXED_RATE_BASES (17).",
+          "scenario": "One Allocator combining NET Rate and RateGross entries with a fixed Amount total",
+          "mitigation": "Split the rate entries into separate Allocators (one for NET Rate, one for RateGross), or drop the fixed Amount total — with fix = 0 the two bases coincide and mixing is allowed.",
+          "evidence": "allocator=${mixed_rate_bases_index}, guard=${mixed_rate_bases_guard}",
+          "stakeholders": ["owner"]
         }
       ]
     },

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

@@ -11,6 +11,8 @@
     "indemnity_none": "indemnity is None (the ruling carries no compensation).",
     "weight_concentrated": "The Arbitration rule gives disproportionate voting weight to one voter.",
     "expects_status_enum": "The caller expects status fields to be a Move enum (they are u8 constants).",
+    "escrow_released_before_case": "Escrow refunds on the case's order predate the case filing (refund→claim ordering) — caller supplies from escrow forensics (allocation balance vs order amount; refund event timestamps vs case creation time).",
+    "escrow_deficit_display": "Rendered escrow deficit — the order principal that already flowed out of the escrow ('?' when unknown).",
     "max_votor_count": "KERNEL CONSTANT — maximum voters per Arb (MAX_VOTOR_COUNT).",
     "withdraw_duration_time_ms": "KERNEL CONSTANT — post-arbitration withdraw lock in milliseconds (WITHDRAW_DURATION_TIME)."
   },
@@ -24,7 +26,7 @@
           "when": { "field": "invalid_transition", "op": "eq", "value": true },
           "level": "high",
           "title": "7-state machine — invalid transitions can deadlock the arbitration",
-          "description": "Arb has a 7-state machine: Principal_confirming(0) → Arbitrator_confirming(1) → Voting(2) → Arbitrated(3) → Objectionable(4) → Finished(5) → Withdrawn(6). reset() can revert from {1, 4} back to 0. Each op asserts the current status; calling an op out of order aborts with E_STATUS_NOT_MATCH (3). Repeated mis-calls leave the Arb stuck in a non-terminal state with no automatic recovery.",
+          "description": "Arb has a 7-state machine (u8 constants, not an enum). A NEW case starts at Arbitrator_confirming(1) — Principal_confirming(0) is ONLY reachable via reset(). Forward path: 1 → Voting(2) via arbitrator_confirm → Arbitrated(3) via the ruling (indemnity set, capped at 3x order amount, enforced at award time) → Finished(5) via the compensation claim, or Objectionable(4) via objection. reset() reverts {1, 4} back to 0 and CLEARS indemnity + votes. withdraw (fee sweep) goes 5→6 immediately, or 3→6 after WITHDRAW_DURATION_TIME when no objection was filed. Each op asserts the current status; calling an op out of order aborts with E_STATUS_NOT_MATCH (3). Repeated mis-calls leave the Arb stuck in a non-terminal state with no automatic recovery.",
           "scenario": "Caller calls vote() when status is still Arbitrator_confirming; abort blocks progress",
           "mitigation": "Strictly validate the current status before submitting any Arb op. The SDK should expose a status-aware state machine helper. Provide a recovery path (reset) for Arbitrator_confirming and Objectionable states.",
           "evidence": "invalid_transition=true (status=${status_display})",
@@ -150,6 +152,23 @@
           "stakeholders": ["system"]
         }
       ]
+    },
+    {
+      "rule_id": "R-ARB-09",
+      "dimension": "semantic",
+      "trigger": "escrow refunds on the case's order predate the case filing",
+      "cases": [
+        {
+          "when": { "field": "escrow_released_before_case", "op": "eq", "value": true },
+          "level": "high",
+          "title": "Refund-then-claim ordering — the principal may recover twice",
+          "description": "The order's escrow was already released BEFORE this case was filed (deficit ${escrow_deficit_display}). The claim→refund direction is on-chain closed — the order seals itself once a claim settles — but the reverse ordering is NOT: the principal can still claim the indemnity on top of the refunded principal. The discriminating evidence is fully on-chain: (1) refund/alloc event timestamps vs the case creation time — the decisive ordering signal; (2) escrow balance vs order amount (the deficit); (3) the order's progress path (visited refund terminals); (4) the owner receive history.",
+          "scenario": "Buyer collects a refund via the refund track, then files a dispute and claims the indemnity on top",
+          "mitigation": "At ruling time, net the indemnity against the principal already refunded — compensate the delta, not the full loss. The defendant attaches the escrow forensics to the case statement; tooling refuses to drive the claim for an order whose escrow was already released to the buyer.",
+          "evidence": "escrow_released_before_case=true (deficit=${escrow_deficit_display})",
+          "stakeholders": ["principal", "arbitrator", "voter"]
+        }
+      ]
     }
   ]
 }

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

@@ -14,6 +14,7 @@
     "current_timestamp_ms": "Echo of the current clock reading used for the deadline comparison.",
     "voting_deadline_in_past": "True when the selected voting_deadline is already elapsed at the current timestamp.",
     "vote_voting_guard": "The Guard id the vote claims (vote.voting_guard).",
+    "vote_present": "The context carries a vote op payload (plain or weighted).",
     "voting_guard_list_empty": "True when the on-chain Arbitration.voting_guard list is missing or empty.",
     "vote_guard_registered": "True when the claimed vote Guard is found in the on-chain voting_guard list.",
     "registered_voting_guards": "Comma-joined on-chain voting_guard address list (display form).",
@@ -184,6 +185,32 @@
         }
       ]
     },
+    {
+      "rule_id": "R-AB-2-04",
+      "dimension": "semantic",
+      "trigger": "Plain (open) vote on an Arbitration with an empty voting_guard — NOT permissionless",
+      "cases": [
+        {
+          "when": { "all": [
+            { "field": "vote_present", "op": "eq", "value": true },
+            { "field": "voting_guard_list_empty", "op": "eq", "value": true }
+          ] },
+          "level": "medium",
+          "title": "Open vote is permission-gated (358), not permissionless",
+          "description": "voting_guard is empty (equal weight, 1 person 1 vote) but vote() still asserts ARBITRATION_VOTE=358 — an account without 358 is rejected with E_PERMISSION_DENIED (code 5)",
+          "scenario": "Assuming 'empty voting_guard' means anyone can vote",
+          "mitigation": "Grant ARBITRATION_VOTE=358 to every intended voter via the Arbitration's Permission object; or configure a voting_guard list (354) for weighted voting",
+          "evidence": "voting_guard=empty",
+          "stakeholders": ["voter", "arbiter", "disputant"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "If 358 is not granted to the disputant, the disputant cannot vote in their own case — the ruling proceeds without their input." }
+            ],
+            "gain_paths": []
+          }
+        }
+      ]
+    },
     {
       "rule_id": "R-AB-3-01",
       "dimension": "authority",

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

@@ -1,5 +1,5 @@
 {
-  "comment": "Guard rule pack (R-C/R-X) — declarative form of the retired in-code Guard risk rules (the guard condition-tree lint pack: 32 rules over the serialized root, table classification and the scene ledger). Facts are produced by the kernel extractor (guard-risk.ts, bound to the GUARDQUERY invariant catalog, the witness chain table and the per-scene reentrancy specs); rules only reference fact names. Levels/wording can be retuned per rule and rules can be disabled (enabled=false, trace left) via the judgment document — factory rules can never be deleted or invented here.",
+  "comment": "Guard rule pack (R-C/R-X) — declarative form of the retired in-code Guard risk rules (the guard condition-tree lint pack: 34 rules over the serialized root, table classification and the scene ledger). Facts are produced by the kernel extractor (guard-risk.ts, bound to the GUARDQUERY invariant catalog, the witness chain table, the certain-outcome folder and the per-scene reentrancy specs); rules only reference fact names. Levels/wording can be retuned per rule and rules can be disabled (enabled=false, trace left) via the judgment document — factory rules can never be deleted or invented here.",
   "facts": {
     "has_signer_check": "KERNEL — the serialized root contains a context(Signer) check.",
     "has_clock_check": "KERNEL — the serialized root contains a context(Clock) node.",
@@ -20,6 +20,8 @@
     "root_identifier_is_submission": "KERNEL — when the root is an identifier, the referenced table entry has b_submission=true (false when the entry is missing or constant).",
     "root_query_ids_csv": "KERNEL — all GUARDQUERY ids referenced in the root (numeric ids and resolved names), comma-space joined.",
     "root_has_progress_current_query": "KERNEL — the root queries progress.current (query id 1253).",
+    "queries_arb_status": "KERNEL — the serialized root mentions arb.status (Arb case state query).",
+    "arb_status_transient_gate": "KERNEL — the root queries arb.status AND the table pins a constant numeric value of 5 (Finished): a transient-state gate that arb_withdraw (5→6 Withdrawn) will permanently overtake (testnet o10 refund-edge deadlock).",
     "logic_and_count": "KERNEL — number of logic_and markers in the serialized root.",
     "const_addr_list": "KERNEL — constant Address table entries (b_submission=false, value set) rendered as '#id=value', comma joined.",
     "const_addr_count": "KERNEL — number of constant Address table entries (b_submission=false, value set).",
@@ -87,9 +89,80 @@
     "reentry_found_primitive": "KERNEL — GUARDQUERY name of the anti-reentrancy primitive found in the root.",
     "reentry_evidence": "KERNEL — final detection evidence of the reentrancy scan.",
     "reentry_rationale": "KERNEL — per-scene reentrancy rationale (spec table, Move-verified).",
-    "reentry_mitigation": "KERNEL — per-scene reentrancy mitigation (spec table, Move-verified)."
+    "reentry_mitigation": "KERNEL — per-scene reentrancy mitigation (spec table, Move-verified).",
+    "tree_folds_always_true": "KERNEL — the condition tree provably evaluates to TRUE for every submission and every on-chain state (certain-outcome folder in guard-risk.ts: constant-true table leaf, reflexive comparison of the same operand, unsigned value compared >= the constant 0, or an and/or/logic_not fold of such).",
+    "tree_folds_always_true_reason": "KERNEL — the decisive tautology pattern rendered for the evidence line.",
+    "tree_folds_always_false": "KERNEL — the condition tree provably evaluates to FALSE (always denies: legitimate dead-edge / frozen-service pattern, reported as a notice, not as open access).",
+    "tree_folds_always_false_reason": "KERNEL — the decisive always-false pattern rendered for the evidence line.",
+    "write_guard_scene": "KERNEL — the Guard is bound as a Repository policy write_guard (scene binding_field=write_guard / id repository_write_guard).",
+    "write_guard_no_identity_check": "KERNEL — write_guard scene AND no context(Signer) leaf anywhere in the root: the gate binds a STATE, never the WRITER, so any caller satisfying it may write or overwrite any row.",
+    "write_guard_open": "KERNEL — write_guard scene AND (the tree folds true OR it binds no caller identity): the Repository write is effectively unauthenticated even though the policy has a guard."
   },
   "rules": [
+    {
+      "rule_id": "R-X1-16",
+      "dimension": "data_source_trust",
+      "trigger": "Guard queries arb.status and pins a constant numeric table entry to 5 (Finished) — a transient state that arb_withdraw overtakes (5→6 Withdrawn)",
+      "cases": [
+        {
+          "when": { "field": "arb_status_transient_gate", "op": "eq", "value": true },
+          "level": "high",
+          "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).",
+          "evidence": "Root queries arb.status; table pins a constant numeric value of 5 (Finished).",
+          "stakeholders": ["provider", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-17",
+      "dimension": "logic_gap",
+      "trigger": "The condition tree folds to TRUE for every input (tautology), or a Repository write_guard binds no caller identity — the chain checks that a write_guard EXISTS, never that it PROVES anything",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "write_guard_scene", "op": "eq", "value": true }, { "field": "tree_folds_always_true", "op": "eq", "value": true }] },
+          "level": "critical",
+          "title": "Repository write_guard is a tautology — evidence writes are open to every address",
+          "description": "policy_add_imp asserts only that the write_guard LIST IS NON-EMPTY when a policy's id_from is NONE (repository.move L511-536, E_POLICY_WRITE_GUARD_REQUIRED = 22); nothing on chain evaluates what the Guard authorizes. A Guard that returns true for every caller is therefore accepted silently and is exactly the open door an empty list would have been — the schema warning for 'write_guard missing' does not fire, so the misconfiguration is invisible until exploited. Verified on testnet (test-14, HIGH-04): a NON-merchant signer wrote a forged tracking row for another buyer's order (tx BLA7F62r…), then the merchant's legitimate write simply upserted over it (tx DaZaPn6o…). Every downstream Guard that gates a forward on repository.data EXISTENCE (repository.data has / count where) is satisfied by the forged row, so shipping/return evidence stops being evidence; Repository rows carry no author field, so a signed WTS Proof (proof.signer / proof.about / proof.time) is the only on-chain provenance.",
+          "scenario": "Merchant binds a 'true' placeholder as the evidence Repository write_guard to satisfy the schema; a stranger (or the counterparty in a dispute) pre-writes the shipping/return receipt row and the delivery forward's evidence gate passes on forged data",
+          "mitigation": "Delete the placeholder: bind the writer. Minimum = context(Signer) equality against a constant Address or a vec_contains_address allowlist entry; better = the merchant Permission entity (permission index) or the Order holder via witness, so the row is attributable to the party that owns the order. For evidence that must survive a dispute, store a signed WTS Proof (Prover+Time+Content, repository.move L160-171) instead of a bare string. If genuinely open writes are intended, use id_from=Signer/Clock instead of a write_guard — that is the protocol's declared way to allow anyone.",
+          "evidence": "Tautology: ${tree_folds_always_true_reason}",
+          "stakeholders": ["customer", "provider", "arbitrator"]
+        },
+        {
+          "when": { "all": [{ "field": "write_guard_scene", "op": "eq", "value": true }, { "field": "tree_folds_always_true", "op": "eq", "value": false }, { "field": "write_guard_no_identity_check", "op": "eq", "value": true }] },
+          "level": "high",
+          "title": "Repository write_guard gates a state, not a writer — any qualifying caller may overwrite any row",
+          "description": "The policy has a write_guard, but the tree contains no context(Signer) leaf, so it never asks WHO is writing. The gate can be satisfied by anyone who can present the referenced objects (or who simply owns them), and once satisfied the writer may add OR OVERWRITE any data ID under that policy — Repository rows carry no author. Downstream Guards that check existence (repository.data has) then trust data with no provenance.",
+          "scenario": "Ship-evidence policy guarded only by 'the submitted Order exists': the buyer writes the seller-side shipping receipt themselves, and the deliver forward's evidence check passes",
+          "mitigation": "Add the identity leaf: context(Signer) == a constant merchant Address, or vec_contains_address against an allowlist / permission entity table, or the Order holder derived by witness. Where the row must be provably authored, write a signed WTS Proof rather than a bare value, and have the consuming Guard check proof.attestation == the expected party instead of mere existence.",
+          "evidence": "write_guard scene with no context(Signer) leaf in the root",
+          "stakeholders": ["customer", "provider", "arbitrator"]
+        },
+        {
+          "when": { "all": [{ "field": "tree_folds_always_true", "op": "eq", "value": true }, { "field": "write_guard_scene", "op": "eq", "value": false }] },
+          "level": "high",
+          "title": "Guard is a tautology — whatever it gates is unrestricted",
+          "description": "The condition tree evaluates to true for every submission and every on-chain state, so binding it to a Forward / buy / allocator / usage slot authorizes every caller while LOOKING guarded. Guards are immutable once published (IMMUT-001): the binding cannot be repaired in place, only by standing up new objects and rebinding what is still mutable (L3 fields).",
+          "scenario": "A placeholder guard (constant-true entry, self-comparison, x >= 0) shipped as 'to be filled in later' gets bound to a forward; the workflow accepts any caller from day one and can never be tightened after publish",
+          "mitigation": "Before publishing the host object, replace the placeholder with a real predicate; if the intent is genuinely 'no gate', leave the binding EMPTY instead of binding an always-true Guard (an empty binding is honest; a tautology is a false assurance). Re-check with the Guard analyzer after every edit.",
+          "evidence": "Tautology: ${tree_folds_always_true_reason}",
+          "stakeholders": ["customer", "provider"]
+        },
+        {
+          "when": { "field": "tree_folds_always_false", "op": "eq", "value": true },
+          "level": "low",
+          "title": "Guard is always false — nothing it gates can ever run",
+          "description": "The tree folds to false for every input (the certain-outcome folder found a decisive always-false expression). This is the safe direction of error — it denies rather than opens — and is sometimes intentional (a deliberately frozen edge), but it is far more often a polarity or identifier mistake, and after publish the gated path is dead permanently (IMMUT-001).",
+          "scenario": "Merchant wants 'not yet shipped' and writes logic_equal[current_node, shipped_constant] inside a forward that only runs AFTER shipping; the forward can never fire",
+          "mitigation": "Confirm the intent. If the edge must ever run, fix the predicate before publishing; if it is a permanent block, prefer NOT binding a Guard at all and instead leaving the edge unreachable in the Machine graph (clearer to readers and to the workflow analyzer).",
+          "evidence": "Always-false: ${tree_folds_always_false_reason}",
+          "stakeholders": ["provider"]
+        }
+      ]
+    },
     {
       "rule_id": "R-C1-01",
       "dimension": "data_source_trust",

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

@@ -1,8 +1,11 @@
 {
-  "comment": "Machine rule pack (R-M) — declarative form of the retired in-code Machine risk rules (43 rules across 5 dimensions). Facts are produced by the kernel extractor (machine-risk.ts, bound to MAX_NODE_COUNT and USER_DEFINED_PERM_INDEX_START); rules only reference fact names. Graph walks (entry/terminal/orphan scan, per-node pair counting, per-pair forward counting, duplicate names, unachievable-threshold classification, per-forward permission scans, published-object cross-checks) are sunk into the extractor as first-offender facts. Rules whose retired check had no runtime detection (design guidance only) are catalog stubs: they carry the full wording but a never-true condition, so the finding set matches the retired code exactly. Levels/wording can be retuned per rule and rules can be disabled (enabled=false, trace left) via the judgment document — factory rules can never be deleted or invented here.",
+  "comment": "Machine rule pack (R-M) — declarative form of the retired in-code Machine risk rules (44 rules across 5 dimensions). Facts are produced by the kernel extractor (machine-risk.ts, bound to MAX_NODE_COUNT and USER_DEFINED_PERM_INDEX_START); rules only reference fact names. Graph walks (entry/terminal/orphan scan, per-node pair counting, per-pair forward counting, duplicate names, unachievable-threshold classification, per-forward permission scans, published-object cross-checks) are sunk into the extractor as first-offender facts. Rules whose retired check had no runtime detection (design guidance only) are catalog stubs: they carry the full wording but a never-true condition, so the finding set matches the retired code exactly. Levels/wording can be retuned per rule and rules can be disabled (enabled=false, trace left) via the judgment document — factory rules can never be deleted or invented here.",
   "facts": {
     "has_entry": "At least one Pair has prev_node='' (the workflow entry point).",
     "has_terminal": "At least one node has no outgoing Pair (a terminal exists).",
+    "terminal_nodes_display": "Stop nodes — nodes with NO outgoing Pair (never appear as prev_node), ', '-joined; orders rest here forever.",
+    "no_allocator_published": "The project context is allocator-aware (published_allocators provided) and the set is EMPTY — no Allocator published. Unknown (context without the set, e.g. design-time scans) never fires.",
+    "terminal_fund_exit_uncovered": "At least one stop node exists AND the allocator-aware project context shows no Allocator published — fund-exit coverage gap (R-M5-03).",
     "first_orphaned_node_name": "First-offender — name of the first node with neither an entry/prev reference nor any incoming Pair (absent when none).",
     "node_count": "Number of nodes in the Machine JSON.",
     "node_count_over_limit": "node_count exceeds MAX_NODE_COUNT (chain-limit comparison sunk into the extractor).",
@@ -19,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 neither namedOperator nor permissionIndex (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_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).",
@@ -199,14 +202,14 @@
     {
       "rule_id": "R-M1-11",
       "dimension": "structural",
-      "trigger": "Match node names against regex /(^|_)(disputed?|refund(?:ed)?|arbitration|arb)(_|$)/i (catches both exact names like 'refunded' and compound fund-flow terminals like 'deposit_refunded'/'deposit_deducted'; business states like 'return_approved'/'damage_confirmed'/'cancelled'/'returned' do NOT match) — catalog stub: the retired check was not implemented",
+      "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",
       "cases": [
         {
           "when": { "field": "always_true", "op": "eq", "value": false },
           "level": "critical",
           "title": "Dispute anti-pattern — machine illegally models dispute flow",
-          "description": "Machine contains nodes named 'disputed', 'refunded', 'arb', 'arbitration', 'dispute', or 'refund'. This is a CRITICAL design anti-pattern because dispute is INDEPENDENT of the machine workflow. Dispute flows through: Order → dispute filed on the Arbitration → Arb case → arbiter ruling → fee withdrawal by order holder. Arbitrators are configured in the Arbitration's voting_guard list, NOT in Permission. Merchants who model dispute in the machine (e.g., 'disputed → refunded' forward guarded by Permission index 1500) create dead-end paths because no one has Permission 1500 — arbitrators are NOT Permission holders.",
-          "mitigation": "Remove all dispute/refund nodes from the machine. Instead: (1) bind an Arbitration object to the Service via Service.arbitrations, (2) configure arbitrators via Arbitration.voting_guard_add, (3) deposit compensation_fund to the Service. Disputes are then filed against the order within the Arbitration object — completely independent of the machine workflow."
+          "description": "Machine contains nodes named 'disputed', 'refunded', 'arb', 'arbitration', 'dispute', or 'refund'. This is a CRITICAL design anti-pattern because dispute resolution is a SEPARATE system from the Machine workflow. Dispute flows through: Order → dispute filed on the Arbitration (Arb case created, dispute fee escrowed in the case) → arbitrator confirm → voting → ruling (indemnity capped at 3x order amount, enforced at award time) → compensation claim pays the awarded amount from the Service's compensation_fund to the ORDER OWNER (the call itself is permissionless — any keeper/agent can drive it, the recipient is hard-bound to the order owner) → the case fee is released to the Arbitration via arb_withdraw (permission 364, the arbitration operator — NOT the order holder). Arbitrators are configured in the Arbitration's voting_guard list, NOT in Permission. Merchants who model dispute in the machine (e.g., 'disputed → refunded' forward guarded by Permission index 1500) create dead-end paths because no one has Permission 1500 — arbitrators are NOT Permission holders.",
+          "mitigation": "Remove all dispute/refund nodes from the machine. Instead: (1) bind an Arbitration object to the Service via Service.arbitrations, (2) configure arbitrators via Arbitration.voting_guard_add, (3) deposit compensation_fund to the Service. Disputes are then filed against the order within the Arbitration object — completely independent of the machine workflow. BOUNDARY (design intent, never 'fix' it): Arbitration (compensation_fund payouts) and Allocator (escrow distribution) keep independent fund sources and lifecycles by design. Cross-system checks belong in allocator Guards as READ-ONLY evidence (order.claimed_by / arb.indemnity — see pattern.arb_status_escrow_holdback), NOT in arb-linked Machine nodes/forwards or protocol state sync — coupling the two systems opens the refund+compensation double-payout path."
         }
       ]
     },
@@ -384,15 +387,15 @@
     {
       "rule_id": "R-M3-01",
       "dimension": "permission",
-      "trigger": "Check each forward has at least one of namedOperator or permissionIndex",
+      "trigger": "Check each forward has at least one executor binding: namedOperator, permissionIndex, or Guard (Guard-only is valid — verified via Passport)",
       "cases": [
         {
           "when": { "field": "first_noperm_forward_name", "op": "present" },
           "level": "critical",
           "title": "Forward without permission",
-          "description": "Forward has neither namedOperator nor permissionIndex. Cannot be executed.",
-          "mitigation": "Set namedOperator='' for OrderHolder, or set permissionIndex.",
-          "evidence": "Forward \"${first_noperm_forward_name}\" in Pair (${first_noperm_prev} -> ${first_noperm_next}) has no 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).",
+          "evidence": "Forward \"${first_noperm_forward_name}\" in Pair (${first_noperm_prev} -> ${first_noperm_next}) has no executor binding.",
           "exposure": {
             "loss_parties": [
               { "role": "buyer", "basis": "The affected forward has no executor — orders that route through this Pair can never advance past it and their escrowed funds freeze." },
@@ -620,14 +623,22 @@
     {
       "rule_id": "R-M5-03",
       "dimension": "environment",
-      "trigger": "Check if Service.order_allocators is configured for each terminal node — catalog stub: the retired check was not implemented",
+      "trigger": "Check if Service.order_allocators is configured for each terminal node (stop-node fund-exit coverage)",
       "cases": [
         {
-          "when": { "field": "always_true", "op": "eq", "value": false },
+          "when": { "field": "terminal_fund_exit_uncovered", "op": "eq", "value": true },
           "level": "high",
           "title": "Allocation configuration incomplete",
-          "description": "Service's order_allocators not configured or misconfigured. Terminal node funds cannot be distributed.",
-          "mitigation": "Configure Service.order_allocators, one Allocator per terminal node."
+          "description": "Machine has stop nodes (no outgoing Pair) but no Allocator is published in the project. Funds at those nodes can be neither distributed nor refunded — and Machine + Allocator are immutable after publish (IMMUT-001), so an uncovered stop node strands escrowed funds permanently.",
+          "mitigation": "Before Service publish, bind Service.order_allocators fund-exit rules to EVERY stop node: withdrawal (release) AND refund paths. Review-dependent release is a TIME-GATE on the same exit (reviewed, OR unreviewed after T) — never a parallel edge or a separate node without its own exit.",
+          "evidence": "Stop nodes without allocation coverage: ${terminal_nodes_display} (no Allocator published).",
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "Escrowed order funds resting at an uncovered stop node can never be refunded to the buyer after publish (immutable topology)." },
+              { "role": "merchant", "basis": "The merchant release share at the same node can never be withdrawn." }
+            ],
+            "gain_paths": []
+          }
         }
       ]
     },
@@ -701,6 +712,20 @@
           "evidence": "Object dependency table incomplete. Missing Guards: ${missing_guards_display}"
         }
       ]
+    },
+    {
+      "rule_id": "R-M5-09",
+      "dimension": "environment",
+      "trigger": "Design-time review: allocator coverage over ALL stop nodes incl. review-gated and dispute exits — catalog stub: requires cross-object (Service x Machine) evaluation; enforced via publish schema guidance + pattern.fund_flow_stop_node_coverage",
+      "cases": [
+        {
+          "when": { "field": "always_true", "op": "eq", "value": false },
+          "level": "high",
+          "title": "Stop-node fund-exit coverage not reviewed",
+          "description": "Every node where an order can rest — terminal nodes AND waiting states such as review windows or open disputes — must have BOTH a withdrawal and a refund allocation rule evaluated at Service publish. Review-gated release is a time variant of the completed exit; dispute release is an arb.indemnity-gated edge (R-X1-16). The stop-node list is derived from THIS business's rest states, not a fixed vocabulary: wowok grows arbitrary commerce systems from Move-native primitives.",
+          "mitigation": "Run the coverage checklist of pattern.fund_flow_stop_node_coverage (guard-design-patterns) against the planned Machine before publishing Service; publish is irreversible (IMMUT-001)."
+        }
+      ]
     }
   ]
 }

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. 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) 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.",
           "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}",
@@ -262,7 +262,7 @@
           ] },
           "level": "high",
           "title": "Cannot file new dispute after claimed_by is set",
-          "description": "Order.claimed_by is set — any new dispute() call aborts E_ORDER_ALREADY_CLAIMED. arb_confirm/arb_objection trigger dispute() internally.",
+          "description": "Order.claimed_by is set — any new dispute() call and any further payout claim on the order abort E_ORDER_ALREADY_CLAIMED. arb_confirm/arb_objection trigger dispute() internally; the owner receive entries abort for escrow payouts (the provider release track pays direct and stays usable).",
           "scenario": "Buyer claims compensation then tries to file additional dispute",
           "mitigation": "Resolve ALL disputes BEFORE calling arb_claim_compensation. claimed_by is terminal for dispute flow.",
           "evidence": "operation=${operation}, claimed_by_set=true",

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

@@ -4,6 +4,7 @@ export interface ArchetypeTemplate {
     id: string;
     industry: Industry;
     variant: string;
+    product_ref: string;
     archetype: "leader" | "challenger";
     phase: 1 | 2 | 3;
     machine_shape: ModeMachineNode[];
@@ -18,8 +19,9 @@ export interface ArchetypeTemplate {
     user_inputs: string[];
     key_risk: string;
     build_notes: string[];
+    time_anchors?: Record<string, string>;
 }
-export declare const BUILTIN_TEMPLATES_VERSION = 2;
+export declare const BUILTIN_TEMPLATES_VERSION = 17;
 export declare const BUILTIN_TEMPLATES: ArchetypeTemplate[];
 export declare const TEMPLATE_KEYWORDS: Record<string, string[]>;
 export declare function getBuiltinTemplate(id: string): ArchetypeTemplate | undefined;