@wowok/agent-mcp 3.4.3 → 3.4.4

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

@@ -0,0 +1,534 @@
+{
+  "comment": "Graph-level cross-object findings (the analyze.ts emitters). Kernel copy (title/detail/suggestion/amounts) stays in code; this pack owns the SWITCH, the LEVEL and the LOSS/GAIN ATTRIBUTION as data. Levels that the kernel computes at run time (fund shortfall, control fanout, detector signal severity, reward slot viability) are referenced with fact:<name>; every fact name below is produced by a kernel extractor. Users may retune a level, rewrite attribution, or disable a rule id (trace left) — case lists replace wholesale.",
+  "facts": {
+    "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 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)",
+    "ac_signal_level": "Detector-assigned signal severity (high | medium | low)",
+    "ac_shell_code": "Shell-merchant signal code (shell_no_arbitration | shell_funded_no_arbitration | shell_no_machine)"
+  },
+  "rules": [
+    {
+      "rule_id": "R1",
+      "dimension": "structural",
+      "trigger": "Service and an Arbitration service share a controlling EOA across DISTINCT permissions",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "high",
+          "title": "Same-controller arbitration risk: the service and the arbitration service are controlled by the same EOA",
+          "description": "Cross-group control overlap lets one EOA influence both the arbitrated service and the ruling outcome.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "Disputes against this service are ruled under a permission group the service controller influences — indemnity can be set to zero and feedback shaped against the buyer." },
+              { "role": "system", "basis": "Reputation and recommendation signals absorb manipulated rulings and feedback." }
+            ],
+            "gain_paths": [
+              {
+                "role": "merchant",
+                "path": "As owner/admin of the arbitration permission, ${eoa} can grant the ruling role to its own addresses, rule own-service disputes (indemnity 0), and withdraw dispute fees.",
+                "viability": "viable",
+                "gate": "Owner/admin control of the permission object implies member-management power; verify actual member tables and vote weights to confirm the rubber-stamp path end-to-end."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R2",
+      "dimension": "structural",
+      "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 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." }
+            ],
+            "gain_paths": [
+              {
+                "role": "merchant",
+                "path": "The fund is withdrawable by service-permission members at any time; keeping it below the 3x ceiling preserves the unilateral option to stay defunded before an adverse ruling.",
+                "viability": "viable",
+                "gate": "This is the defunding position itself (permission-gated withdrawal) — not a theft path; no third party gains."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R3",
+      "dimension": "structural",
+      "trigger": "A single EOA controls 3+ Service/Machine/Treasury objects",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "fact:r3_level",
+          "title": "Permission concentration: a single EOA controls multiple business-critical objects",
+          "description": "Business scale concentrated in one control set; dispersion assumptions behind trust signals weaken.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "Terms across all controlled services (allocators, rewards, arbitrations, machines) can change in one hand without structural friction." },
+              { "role": "system", "basis": "Concentration undermines the dispersion assumptions behind market-level trust signals." }
+            ],
+            "gain_paths": [
+              {
+                "role": "merchant",
+                "path": "Coordinated unilateral reconfiguration of every controlled object from one permission group.",
+                "viability": "conditional",
+                "gate": "Bounded by each service's setting_lock_duration (R6 flags services without it); verify lock durations to size the real window."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R4",
+      "dimension": "structural",
+      "trigger": "The only Forward before a terminal state has a single operator and no fallback Guard",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "medium",
+          "title": "Workflow single point: the only Forward before a terminal state has a single operator and no fallback Guard",
+          "description": "One party can stall the path to the terminal state; availability hold-up without fund redirection.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "Orders stall before the terminal state — delivery and the escrowed order funds freeze until the sole operator returns." },
+              { "role": "supplier", "basis": "Their fulfillment leg cannot advance past the blocked node either." }
+            ],
+            "gain_paths": [
+              {
+                "role": "collaborator",
+                "path": "The sole operator (${only}) gains hold-up leverage: counterparties must concede terms to unblock the workflow.",
+                "viability": "conditional",
+                "gate": "Realized only if that operator actually bargains; the defect is availability risk with no fund-redirection path."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R6",
+      "dimension": "structural",
+      "trigger": "Published Service with setting_lock_duration = 0",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "medium",
+          "title": "Missing setting lock: published Service has setting_lock_duration=0",
+          "description": "All service bindings and fund withdrawals are instantly mutable; ordered terms carry no waiting period.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "Terms the buyer ordered under can be rewritten instantly after ordering — allocator routing, reward claims, arbitration bindings, workflow and the fund's withdrawability all move in one transaction." }
+            ],
+            "gain_paths": [
+              {
+                "role": "merchant",
+                "path": "Instant unilateral rewrite of any service binding, including compensation_fund withdrawal, with no waiting period.",
+                "viability": "viable",
+                "gate": "No lock is set — the permission-gated entries execute immediately; the buyer's only protection is choosing not to order."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R7-treasury",
+      "dimension": "structural",
+      "trigger": "Treasury carries external_withdraw_guard entries (permission-free external release path)",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "critical",
+          "title": "Object-user CRITICAL: Treasury has a permission-free external release path",
+          "description": "Only the Guard's boolean verdict stands between an external caller and the balance; guard strength is unverifiable from topology.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "The treasury balance belongs to the organization behind its Permission; a weak-guard release pays the caller directly and no clawback entry exists." }
+            ],
+            "gain_paths": [
+              {
+                "role": "neutral",
+                "path": "An external caller satisfying the external_withdraw_guard releases treasury balance to their own address — the destination is forced to the transaction sender, so the caller is always the gainer.",
+                "viability": "unverifiable",
+                "gate": "Decided inside the guard predicate (amount slot binding). Disclosure duty: full guard definitions plus a testnet regression where recipient != sender aborts with code 10."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R7-reward",
+      "dimension": "structural",
+      "trigger": "Reward carries claim-guard entries (permission-free claim path with a claim-time payout slot)",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "critical",
+          "title": "Object-user CRITICAL: Reward has a permission-free claim path with an unverifiable payout slot",
+          "description": "The payout address is read from the claim-time passport submission; a guard that does not bind the slot lets any passing party claim the pool.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "The reward pool belongs to its funder; the claim entry has no clawback or owner-withdraw path, so any successful third-party claim permanently drains the pool." }
+            ],
+            "gain_paths": [
+              {
+                "role": "neutral",
+                "path": "A third party whose passport satisfies the claim guard fills the payout slot with their own address and claims the pool.",
+                "viability": "fact:r7_slot_viability",
+                "gate": "Payout-slot viability per entry: ${r7_slot_audit}"
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "A1",
+      "dimension": "economic",
+      "trigger": "Allocation Rate/Surplus/max configuration has triggerable structural defects",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "medium",
+          "title": "Allocation structure mismatch: Rate/Surplus/max configuration has triggerable structural defects",
+          "description": "Broken sharing tables abort or overpay on the guard trigger; pools carrying escrow freeze or drain.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "The allocation pool pays out on the guard trigger; a structurally broken sharing table either aborts the payout or overpays beyond the intended split." },
+              { "role": "buyer", "basis": "When the pool carries the buyer's escrowed order funds, an abort freezes release and an overpay drains the escrow." }
+            ],
+            "gain_paths": [
+              {
+                "role": "neutral",
+                "path": "A trigger caller collects the mis-sized payout (over-max fixed amounts, ambiguous surplus ownership).",
+                "viability": "conditional",
+                "gate": "Executable only once the guard conditions hold; the misconfiguration decides whether the call aborts or overpays."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "A2",
+      "dimension": "economic",
+      "trigger": "Transferable + 30d+ window + fixed-amount discount without benchmark",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "low",
+          "title": "Discount combination: transferable + long validity window + fixed-amount discount without benchmark",
+          "description": "The combination leaves room for coupon hoarding and resale arbitrage near face value.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "Fixed-amount discounts redeemed at face value erode margin; transferability lets one discount concentrate on the highest-value cart." }
+            ],
+            "gain_paths": [
+              {
+                "role": "neutral",
+                "path": "Hoard transferable fixed-amount discounts and resell them near face value (stacking arbitrage).",
+                "viability": "viable",
+                "gate": "Transferable + long window + no benchmark are exactly the resale preconditions; only market friction limits the spread."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "A3",
+      "dimension": "economic",
+      "trigger": "Arbitration with fee = 0 and empty usage_guard",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "medium",
+          "title": "Remedy cost structure: zero fee + no usage gate gives malicious disputes a positive-expected-value setup",
+          "description": "Filing a dispute carries no structural upfront cost; griefing and coercion become rational strategies.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "Cost-free malicious disputes consume the merchant's adjudication attention and can freeze the disputed order for the objection window." },
+              { "role": "buyer", "basis": "Arbitrator bandwidth spent on griefing cases delays genuine buyers' rulings." }
+            ],
+            "gain_paths": [
+              {
+                "role": "neutral",
+                "path": "File disputes at zero structural cost to grief or pressure counterparties — the setup has positive expected value even when every ruling loses.",
+                "viability": "viable",
+                "gate": "fee=0 and no usage gate are the exact preconditions; the 3x payout cap never triggers without a favorable ruling, so the gain is coercion, not payout."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "G2",
+      "dimension": "game",
+      "trigger": "A Forward's operable-party pool has size 1 (hold-up slot)",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "low",
+          "title": "Operator replaceable pool = 1: hold-up slot",
+          "description": "A single irreplaceable operator holds bargaining power at the workflow node.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "Order progress depends on one irreplaceable operator — hold-up terms or stall risk fall on the counterparties." },
+              { "role": "supplier", "basis": "Their downstream leg shares the same bottleneck." }
+            ],
+            "gain_paths": [
+              {
+                "role": "collaborator",
+                "path": "The pool-of-1 operator extracts hold-up rent (delay, renegotiated fees) at the workflow node.",
+                "viability": "conditional",
+                "gate": "Realized only through actual bargaining; no fund-redirection path — the protocol cannot force the rent."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "AC1",
+      "dimension": "integrity",
+      "trigger": "Windowed order buyers are the selling service's controlling EOAs (self-trading)",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "high",
+          "title": "Fake-order suspicion: windowed order buyers are the selling service's controlling EOA (self-trading)",
+          "description": "Buyer and seller sit in one control set; funds circulate internally and inflate the sales record.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "system", "basis": "Sales volume and reputation statistics absorb fake circulation, distorting trust scores and recommendation ranking for everyone." },
+              { "role": "buyer", "basis": "Buyers comparing services on inflated volume are misled at decision time." }
+            ],
+            "gain_paths": [
+              {
+                "role": "merchant",
+                "path": "Self-traded volume inflates the service's sales record and market exposure at zero net cost (funds circulate internally).",
+                "viability": "viable",
+                "gate": "Buyer and seller sit in one control set — the loop is self-executing; only detection and de-weighting remove the benefit."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "AC2",
+      "dimension": "integrity",
+      "trigger": "Reciprocal buy/sell role-swapping fund loops in the window",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "fact:ac_signal_level",
+          "title": "Wash-trading suspicion: reciprocal buy/sell role-swapping fund loops in the window",
+          "description": "Two control sets buy each other's services; the two-way volume may be mutually staged wash trading.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "system", "basis": "Mutually staged volume pollutes the shared trust statistics both services rank on." },
+              { "role": "buyer", "basis": "Cross-referenced sales records read as independent demand signals." }
+            ],
+            "gain_paths": [
+              {
+                "role": "merchant",
+                "path": "Both control sets gain inflated sales records at reciprocal net-zero fund cost.",
+                "viability": "viable",
+                "gate": "Each side's purchase is funded by the other's payment — the loop is self-sustaining until detected."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "AC3",
+      "dimension": "integrity",
+      "trigger": "Completed positive-amount orders lack an Allocation object (no fund closure)",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "fact:ac_signal_level",
+          "title": "Missing fund closure: completed positive-amount orders lack an Allocation object",
+          "description": "Completion is recorded with no money movement; volume reputation without delivering value.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "system", "basis": "Completion records without fund closure inflate the reputation statistics the completion status feeds." },
+              { "role": "buyer", "basis": "Reputation built on non-economic completions misleads service comparison." }
+            ],
+            "gain_paths": [
+              {
+                "role": "merchant",
+                "path": "Completion (and its reputation weight) is recorded with no money movement — volume reputation without delivering value.",
+                "viability": "viable",
+                "gate": "The missing Allocation is the gain: no escrow leg exists to contradict the completion status."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "AC4",
+      "dimension": "integrity",
+      "trigger": "Published Service missing arbitration binding / funded-without-arbitration / missing Machine binding (per signal code)",
+      "cases": [
+        {
+          "when": { "field": "ac_shell_code", "op": "eq", "value": "shell_no_arbitration" },
+          "level": "fact:ac_signal_level",
+          "title": "Shell merchant: published Service has no arbitration binding, disputes have no remedy path",
+          "description": "Buyers have no selectable arbitration service after ordering; disputes cannot enter adjudication.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "Post-order disputes have no adjudication venue — the buyer's only recourse for undelivered work is off-chain and unenforceable." }
+            ],
+            "gain_paths": [
+              {
+                "role": "merchant",
+                "path": "Operates without funding an arbitration group and without any structural path a winner could enforce against it.",
+                "viability": "viable",
+                "gate": "No arbitration binding means no on-chain ruling can ever be produced against this service; the saving is structural."
+              }
+            ]
+          }
+        },
+        {
+          "when": { "field": "ac_shell_code", "op": "eq", "value": "shell_funded_no_arbitration" },
+          "level": "fact:ac_signal_level",
+          "title": "Floating payout funds: compensation fund is funded but no Arbitration exists, payouts cannot be adjudicated or released",
+          "description": "Funded compensation without an adjudicator: payout guarantees cannot ever trigger.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "The advertised guarantee cannot pay out: no adjudicator exists to rule, and the buyer's statutory compensation claim has no trigger path." }
+            ],
+            "gain_paths": [
+              {
+                "role": "merchant",
+                "path": "Harvests the guarantee's marketing value while the fund stays withdrawable and unreachable by any claim.",
+                "viability": "viable",
+                "gate": "The fund is recoverable through the service permission, and with no arbitration binding no ruling can ever unlock it for a buyer."
+              }
+            ]
+          }
+        },
+        {
+          "when": { "field": "ac_shell_code", "op": "eq", "value": "shell_no_machine" },
+          "level": "fact:ac_signal_level",
+          "title": "Shell merchant: published Service has no Machine binding, no structured fulfillment workflow",
+          "description": "No frozen workflow template; delivery and completion carry no on-chain structural constraints.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "No frozen fulfillment stages exist — progress claims rest entirely on the merchant's word and manual refunds." }
+            ],
+            "gain_paths": [
+              {
+                "role": "merchant",
+                "path": "Fulfills (or not) outside any structural constraint; completion and delivery stay fully discretionary.",
+                "viability": "viable",
+                "gate": "Without a Machine there is no node state to contradict the merchant's claims — the discretion IS the gain."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "AC5",
+      "dimension": "integrity",
+      "trigger": "Freshly-registered accounts casting registrar votes in a burst (voter-side, V-PROF)",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "fact:ac_signal_level",
+          "title": "Vote-noise suspicion: freshly-registered accounts are casting votes in a burst",
+          "description": "New accounts voting in volume read as an organized reputation push, not organic discovery.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "system", "basis": "Account-level vote aggregates absorb coordinated pushes, distorting the discovery signals every participant ranks on." },
+              { "role": "buyer", "basis": "Buyers reading like/favor counts as social proof are shown a manufactured signal." }
+            ],
+            "gain_paths": [
+              {
+                "role": "merchant",
+                "path": "A burst of fresh-account votes inflates the account-level reputation of the targets the push favors.",
+                "viability": "viable",
+                "gate": "Registrar votes cost only gas and carry no order binding — the gate is detection and de-weighting, not the chain."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "AC6",
+      "dimension": "integrity",
+      "trigger": "Mutual votes between address pairs (voter-side, V-PROF)",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "fact:ac_signal_level",
+          "title": "Vote-ring suspicion: mutual votes between address pairs",
+          "description": "Symmetric voting pairs are the cheapest way to manufacture mutual account-level reputation.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "system", "basis": "Ring votes correlate accounts that read as independent reputations, polluting pairwise trust statistics." },
+              { "role": "buyer", "basis": "Rings inflate the accounts buyers compare against, skewing discovery." }
+            ],
+            "gain_paths": [
+              {
+                "role": "merchant",
+                "path": "Each ring member gains a like-backed reputation at pure gas cost — the reciprocity is the whole scheme.",
+                "viability": "viable",
+                "gate": "No on-chain primitive binds a vote to an order; only correlation analysis reveals the ring."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "AC7",
+      "dimension": "integrity",
+      "trigger": "One target's votes dominated by low-credibility accounts (voter-side, V-PROF)",
+      "cases": [
+        {
+          "when": { "field": "kernel_fired", "op": "truthy" },
+          "level": "fact:ac_signal_level",
+          "title": "Vote-noise suspicion: an address's votes are dominated by low-credibility accounts",
+          "description": "The account-level aggregate may be noise rather than signal; rank by the order-backed layer instead.",
+          "exposure": {
+            "loss_parties": [
+              { "role": "system", "basis": "A flooded vote ring makes the target's account-level reputation meaningless as a ranking input." },
+              { "role": "buyer", "basis": "Buyers trusting the flooded account's like count are misled at decision time." }
+            ],
+            "gain_paths": [
+              {
+                "role": "merchant",
+                "path": "Flooding a target (a competitor or one's own account) with fresh/zero-history votes rewrites its social proof at gas cost.",
+                "viability": "viable",
+                "gate": "The vote ring has no order gate — the flood is undetectable on-chain, only by voter-credibility re-projection."
+              }
+            ]
+          }
+        }
+      ]
+    }
+  ]
+}

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

@@ -70,6 +70,9 @@
     "rc3_06_level_rationale": "KERNEL — final level rationale for the evidence line.",
     "rc4_01_comparison_detail": "KERNEL — detected comparison operators rendered 'logic_equal(==) logic_not_equal(!=)' (blank when absent).",
     "rc4_01_comparison_ops": "KERNEL — detected comparison operators rendered '== !=' (blank when absent).",
+    "rc4_01_identity_legal": "KERNEL — the root carries a LEGAL identity form (order.owner equality / order.agent leg / order.service binding / permission.(owner|admin) role) => the blanket 'direction needs manual confirmation' WARN is silenced (K3 C4 bkg F-04).",
+    "rc4_01_identity_form": "KERNEL — the detected identity form label: 'order.owner ==', 'order.agent leg', 'order.service binding', 'permission role', or 'unrecognized'.",
+    "rc4_01_settlement_buyer_trigger": "KERNEL — a BUYER-form leg (order.owner equality / order.agent) on a NON-refund order_allocators rail => the role-reversal WARN stays: the buyer's signature would release the merchant's money. Refund rails are exempt (user slot 0 = submitted Order).",
     "rc4_02_has_greater_or_equal": "KERNEL — the root uses logic_as_u256_greater_or_equal (Clock boundary form).",
     "rc4_02_has_greater": "KERNEL — the root uses logic_as_u256_greater (substring semantics).",
     "rc4_02_comparison_ops": "KERNEL — detected comparison operators rendered '>= >' (blank when absent).",
@@ -646,16 +649,26 @@
     {
       "rule_id": "R-C4-01",
       "dimension": "system_context_risk",
-      "trigger": "Guard contains context(Signer) check; need to confirm comparison direction (== vs !=) and compared object role",
+      "trigger": "Guard contains context(Signer) check; need to confirm comparison direction (== vs !=) and compared object role. K3 C4 (2026-11-08): the LEGAL caller-identity set for fund rails — order.owner==signer | order.agent has signer | order.service binding leg | permission.owner/admin role leg (the guard face of permission-index 1000/1001 rails) — is SILENT; the WARN stays only for (a) a buyer-form leg firing a NON-refund allocator rail (the settlement role-reversal disclosure) and (b) unrecognized identity forms.",
       "cases": [
         {
-          "when": { "field": "has_signer_check", "op": "eq", "value": true },
+          "when": { "all": [{ "field": "has_signer_check", "op": "eq", "value": true }, { "field": "rc4_01_settlement_buyer_trigger", "op": "eq", "value": true }] },
+          "level": "medium",
+          "title": "Buyer-triggered settlement (role-reversal disclosure): identity form ${rc4_01_identity_form}",
+          "description": "This allocator rail's ONLY caller face is the order-holder identity (${rc4_01_identity_form}) — the BUYER's signature is what releases the rail's money. On a NON-refund allocator rail that is the disclosed role reversal: the buyer can time or withhold the payout and the merchant cannot settle unilaterally. Legal by design when buyer-controlled release IS the contract (buyer-claimed completion), silent otherwise per the C4 relaxation — service-binding and permission-role faces are merchant-side by construction and are NOT warned. Refund rails (slot-0 Order submission) are exempt: a buyer-triggered refund is the correct semantics.",
+          "scenario": "Buyer claims completion and fires the settlement rail; or withholds the signature and the merchant's revenue is stuck despite delivered work",
+          "mitigation": "If unilateral merchant settlement is intended, widen the rail's caller face to the C4-legal set: a permission.owner/admin role leg (riding the merchant permission rail 1000/1001) or an order.service binding leg plus the permission-index rail. Keep the buyer-only face only where buyer-controlled release is the contract.",
+          "evidence": "Scene: service_order_allocators_guard. Identity form: ${rc4_01_identity_form}. Comparison: ${rc4_01_comparison_ops}",
+          "stakeholders": ["customer", "provider"]
+        },
+        {
+          "when": { "all": [{ "field": "has_signer_check", "op": "eq", "value": true }, { "field": "rc4_01_identity_legal", "op": "falsy" }] },
           "level": "medium",
           "title": "Signer check direction needs manual confirmation (comparison operator and role match)",
-          "description": "Guard contains a context(Signer) check. Signer is a Type4 system context, from TransactionContext.sender() (transaction initiator address).\nDetected comparison: ${rc4_01_comparison_detail}\nManual confirmation required:\n  1) Whether the comparison direction is correct: use == for identity verification (Signer == authorized address), use != for exclusion (Signer != blacklist address)\n  2) Whether the compared object role is correct: buy_guard should compare the Customer address, Forward.guard may compare the Provider address\n  3) Wrong direction causes reverse effect: == blacklist address would only allow blacklisted users",
+          "description": "Guard contains a context(Signer) check whose identity form is NOT in the C4-legal caller set (order.owner==signer | order.agent | order.service binding | permission.owner/admin role). Signer is a Type4 system context, from TransactionContext.sender() (transaction initiator address).\nDetected comparison: ${rc4_01_comparison_detail}\nManual confirmation required:\n  1) Whether the comparison direction is correct: use == for identity verification (Signer == authorized address), use != for exclusion (Signer != blacklist address)\n  2) Whether the compared object role is correct: buy_guard should compare the Customer address, Forward.guard may compare the Provider address\n  3) Wrong direction causes reverse effect: == blacklist address would only allow blacklisted users",
           "scenario": "Wrong direction: Signer == blacklist address would only allow blacklisted users",
-          "mitigation": "1) Confirm logic_equal is used for identity verification (Signer == authorized address);2) Confirm logic_not_equal is used for exclusion (Signer != blacklist address);3) Confirm the compared table constant is the address of the correct role;4) Cover both expected-pass and expected-fail scenarios in gen_passport tests",
-          "evidence": "Comparison: ${rc4_01_comparison_ops}",
+          "mitigation": "1) Confirm logic_equal is used for identity verification (Signer == authorized address);2) Confirm logic_not_equal is used for exclusion (Signer != blacklist address);3) Confirm the compared table constant is the address of the correct role;4) Prefer a C4-legal caller face (order.owner / order.agent / order.service binding / permission.owner-admin role);5) Cover both expected-pass and expected-fail scenarios in gen_passport tests",
+          "evidence": "Comparison: ${rc4_01_comparison_ops}. Identity form: ${rc4_01_identity_form}",
           "stakeholders": ["customer", "provider"]
         }
       ]