@wowok/agent-mcp 3.4.3 → 3.4.4

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

@@ -0,0 +1,586 @@
+{
+  "comment": "Reward rule pack (R-R) — declarative form of the retired in-code Reward risk rules. Facts are produced by the kernel extractor (reward-risk.ts, bound to the Reward Guard/record caps and the Guard constructor table); rules only reference fact names. Array walks (guard_add scans, first-offender picks, intent keyword matching) are sunk into the extractor; R-R-4-01 is a catalog stub (the retired check always returned null) kept silent via a never-true condition, and R-R-7-01 carries two cases for the deposit-dependent level branch. R-R-8-01..05 are the experience-compensation disclosure layer (C-11 decision: buyer-experience compensation rides the Reward object — solvency, withdraw reversibility, claim friction, submission-computed amounts, no clawback), gated on the compensation_intent fact. 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": {
+    "claim": "Guard address being claimed against (ctx.claim).",
+    "guard_add_count": "Number of entries in ctx.guard_add (undefined when absent).",
+    "guard_current": "Current on-chain guard count (ctx.current_guard_count, default 0).",
+    "guard_total": "guard_current + guard_add_count — the would-be total after the batch (only when guard_add is non-empty).",
+    "guard_count_would_exceed": "guard_add is non-empty and guard_total would exceed MAX_GUARD_COUNT_REWARD (chain-limit comparison sunk into the extractor).",
+    "guard_batch_over_limit": "guard_add alone exceeds MAX_GUARD_COUNT_REWARD (schema-level batch overflow).",
+    "max_guard_count": "KERNEL CONSTANT — guards per Reward cap (MAX_GUARD_COUNT_REWARD).",
+    "record_count": "Per-recipient record count (ctx.current_record_count_for_recipient, default 0).",
+    "record_count_at_limit": "record_count has reached MAX_RECORD_COUNT_REWARD (chain-limit comparison sunk into the extractor).",
+    "max_record_count": "KERNEL CONSTANT — records per recipient cap (MAX_RECORD_COUNT_REWARD).",
+    "first_non_address_identifier_index": "First-offender — index into guard_add of the first entry whose GuardIdentifier recipient is not address-typed (absent when none).",
+    "first_non_address_identifier_id": "The offending GuardIdentifier value.",
+    "first_non_u64_amount_index": "First-offender — index into guard_add of the first entry whose amount is a GuardU64Identifier but whose identifier is not u64-typed (absent when none).",
+    "first_non_u64_amount_id": "The offending amount identifier value.",
+    "first_non_u64_amount_value_type": "Resolved passport submission value type for the offending identifier ('unknown' when unresolved).",
+    "first_incompatible_store_from_id_index": "First-offender — index into guard_add of the first entry with store_from_id set that is incompatible with its guard (absent when none).",
+    "first_incompatible_store_from_id_guard": "The offending guard address.",
+    "first_incompatible_store_from_id_value": "The offending store_from_id value.",
+    "first_invalid_pairing_index": "First-offender — index into guard_add of the first entry with no matching Guard constructor (absent when none).",
+    "first_invalid_pairing_recipient": "Rendered recipient type of the invalid pairing ('undefined' when unrecognized).",
+    "first_invalid_pairing_amount": "Rendered amount type of the invalid pairing.",
+    "guard_identifier_recipients_display": "All guard_add guard addresses whose recipient is a GuardIdentifier slot, ', '-joined — empty when there are none.",
+    "owner_receive_set": "ctx.owner_receive is non-null (permission-156 drain path in play).",
+    "new_lock_time": "Requested guard_not_added_expiration_time (ctx.guard_expiration_time, emitted when not undefined).",
+    "current_clock": "Current on-chain clock ms (ctx.current_clock_ms, emitted when present).",
+    "guard_lock_exceeds_year": "The requested guard-addition time-lock sits more than one year (365d) in the future (comparison sunk into the extractor).",
+    "balance_is_zero": "A claim is in play, balance and guard-count context are present, and the current balance parses to zero (BigInt comparison sunk into the extractor).",
+    "lock_until": "Live guard_not_added_expiration_time (ctx.current_guard_not_added_expiration_time, emitted when non-null).",
+    "guard_add_blocked_by_lock": "guard_add is non-empty, the time-lock is Some, and clock <= lock_until (E_GUARD_LOCKED_TIME comparison sunk into the extractor).",
+    "lock_time_in_past": "The requested guard-addition time-lock is not null and sits at or before the current clock (E_GUARD_LOCKED_TIME_INVALID comparison sunk into the extractor).",
+    "known_guards_display": "Live Reward guard addresses (ctx.target_guard_addresses), ','-joined — empty for an empty list.",
+    "claim_guard_not_in_targets": "The claimed guard is absent from ctx.target_guard_addresses (membership comparison sunk into the extractor).",
+    "reward_type": "The Reward's T coin type string (ctx.reward_type).",
+    "coin_type": "Coin type passed by coin_add (ctx.coin_add.coin_type).",
+    "coin_type_mismatch": "coin_add is present with reward_type and its coin type differs from the Reward's T.",
+    "payment_token_type": "Token type carried by receive's Payment (ctx.receive.token_type).",
+    "payment_token_mismatch": "receive is present with reward_type and its token type differs from the Reward's T.",
+    "intent_display": "user_intent_phrases joined and lowercased — the rendered intent text (emitted when phrases are non-empty).",
+    "expected_progress_state": "Progress state baked into the Guard table (ctx.guard_expected_progress_state).",
+    "praise_intent_wrong_node": "Intent matches a praise keyword, the Machine supports the wonder pattern, and the Guard checks a non-wonder node (keyword matching sunk into the extractor).",
+    "wonder_node_without_praise_intent": "Guard checks the wonder node but the intent text matches no praise keyword (keyword matching sunk into the extractor).",
+    "compensation_intent": "The intent text matches an experience-compensation keyword (late delivery / delay / goodwill / experience compensation …; keyword matching sunk into the extractor) — the gate for the R-R-8 disclosure layer (C-11: experience compensation rides the Reward object). Deliberately excludes the bare word 'compensation' (collides with the Service compensation_fund arbitration indemnity).",
+    "has_deposit": "The operation deposits (coin_add or receive present).",
+    "has_identifier_amount": "At least one guard_add entry carries a GuardU64Identifier (submission-computed) amount — positive fact for the R-R-8-04 amount-source-trust disclosure.",
+    "recovery_gap_present": "A deposit or guard_add is in play and no entry carries the owner recovery signature (Signer recipient + GuardU64Identifier amount) — detection sunk into the extractor.",
+    "always_true": "Extractor sentinel — unconditionally true; marks catalog stubs (via eq false) and documentation."
+  },
+  "rules": [
+    {
+      "rule_id": "R-R-1-01",
+      "dimension": "structural",
+      "trigger": "guard_add would exceed MAX_GUARD_COUNT_REWARD (200)",
+      "cases": [
+        {
+          "when": { "all": [
+            { "field": "guard_add_count", "op": "truthy" },
+            { "field": "guard_count_would_exceed", "op": "eq", "value": true }
+          ] },
+          "level": "high",
+          "title": "guard_add would exceed MAX_GUARD_COUNT_REWARD",
+          "description": "Reward has ${guard_current} guards, adding ${guard_add_count} would total ${guard_total}, exceeds MAX_GUARD_COUNT_REWARD ${max_guard_count}. Move aborts with E_GUARD_COUNT_EXCEEDED (3).",
+          "scenario": "Adding too many guards to a single Reward (e.g. milestone reward with > 200 recipients)",
+          "mitigation": "Split into multiple Reward objects, or use GuardIdentifier recipient to handle multiple recipients with a single guard.",
+          "evidence": "current=${guard_current}, add=${guard_add_count}",
+          "stakeholders": ["owner", "service_provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-1-02",
+      "dimension": "structural",
+      "trigger": "claim would push recipient record count to MAX_RECORD_COUNT_REWARD (5200)",
+      "cases": [
+        {
+          "when": { "all": [
+            { "field": "claim", "op": "truthy" },
+            { "field": "record_count_at_limit", "op": "eq", "value": true }
+          ] },
+          "level": "high",
+          "title": "claim blocked — recipient record count at limit",
+          "description": "Recipient already has ${record_count} records, at MAX_RECORD_COUNT_REWARD ${max_record_count}. Next claim will abort with E_RECORD_COUNT_EXCEEDED (8). The recipient can no longer claim from this Reward.",
+          "scenario": "High-frequency claimer hits the 5200-record ceiling (e.g. cashback on every micro-order)",
+          "mitigation": "Owner can create a new Reward for the same recipient, OR redesign the Guard to batch claims (larger amount per claim).",
+          "evidence": "recipient_records=${record_count}",
+          "stakeholders": ["claimer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-1-03",
+      "dimension": "structural",
+      "trigger": "guard_add batch size > MAX_GUARD_COUNT_REWARD (200) — schema-level overflow",
+      "cases": [
+        {
+          "when": { "all": [
+            { "field": "guard_add_count", "op": "truthy" },
+            { "field": "guard_batch_over_limit", "op": "eq", "value": true }
+          ] },
+          "level": "critical",
+          "title": "guard_add batch exceeds absolute limit",
+          "description": "Single guard_add call tries to add ${guard_add_count} guards in one transaction, exceeds MAX_GUARD_COUNT_REWARD ${max_guard_count}. SDK rejects this in operate().",
+          "scenario": "Bulk guard addition without splitting transactions",
+          "mitigation": "Split into multiple transactions, each ≤ ${max_guard_count} new guards.",
+          "evidence": "batch_size=${guard_add_count}",
+          "stakeholders": ["owner"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-2-01",
+      "dimension": "semantic",
+      "trigger": "guard_add with GuardIdentifier recipient where identifier type is not address",
+      "cases": [
+        {
+          "when": { "field": "first_non_address_identifier_index", "op": "present" },
+          "level": "high",
+          "title": "guard_add[${first_non_address_identifier_index}]: recipient GuardIdentifier ${first_non_address_identifier_id} is not address-typed",
+          "description": "RewardGuard constructor requires the recipient identifier to be address-typed. If the identifier type is not address, Move aborts with E_RECIPIENT_IDENTIFIER_NOT_ADDRESS (4).",
+          "scenario": "Misconfigured Guard — recipient identifier is u64/bool instead of address",
+          "mitigation": "Use a Guard with an address-typed identifier for recipient, OR switch to Entity/Signer recipient.",
+          "evidence": "guard_add[${first_non_address_identifier_index}].recipient.GuardIdentifier=${first_non_address_identifier_id}, is_address=false",
+          "stakeholders": ["owner"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-2-02",
+      "dimension": "semantic",
+      "trigger": "guard_add with GuardU64Identifier amount where identifier type is not u64",
+      "cases": [
+        {
+          "when": { "field": "first_non_u64_amount_index", "op": "present" },
+          "level": "high",
+          "title": "guard_add[${first_non_u64_amount_index}]: amount GuardU64Identifier ${first_non_u64_amount_id} is not u64-typed",
+          "description": "RewardGuard constructor resolves the guard's submission value type for the amount identifier; if None or ≠ TYPE_U64, Move aborts with E_AMOUNT_NOT_U64 (5).",
+          "scenario": "Misconfigured Guard — amount identifier is not u64-typed",
+          "mitigation": "Use a Guard with a u64-typed identifier for amount, OR switch to Fixed amount.",
+          "evidence": "guard_add[${first_non_u64_amount_index}].amount.value=${first_non_u64_amount_id}, value_type=${first_non_u64_amount_value_type}",
+          "stakeholders": ["owner"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-2-03",
+      "dimension": "semantic",
+      "trigger": "guard_add with store_from_id set but identifier is not number/address compatible",
+      "cases": [
+        {
+          "when": { "field": "first_incompatible_store_from_id_index", "op": "present" },
+          "level": "medium",
+          "title": "guard_add[${first_incompatible_store_from_id_index}]: store_from_id incompatible with guard",
+          "description": "RewardGuard constructor with store_from_id=Some requires the identifier to be number- or address-compatible. If the identifier type is not number or address, Move aborts with E_STORE_FROM_ID_NOT_COMPATIBLE (12).",
+          "scenario": "Misconfigured Guard — store_from_id points to a non-address/non-number identifier",
+          "mitigation": "Use a compatible identifier, OR drop store_from_id (set to null) if cross-reference is not needed.",
+          "evidence": "guard=${first_incompatible_store_from_id_guard}, store_from_id=${first_incompatible_store_from_id_value}",
+          "stakeholders": ["owner"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-2-04",
+      "dimension": "semantic",
+      "trigger": "guard_add with invalid Recipient × Amount pairing (no matching constructor)",
+      "cases": [
+        {
+          "when": { "field": "first_invalid_pairing_index", "op": "present" },
+          "level": "high",
+          "title": "guard_add[${first_invalid_pairing_index}]: invalid Recipient × Amount pairing",
+          "description": "recipient=${first_invalid_pairing_recipient}, amount=${first_invalid_pairing_amount} — no matching Move constructor. The SDK reward-guard binding will W_ERROR with \"Invalid recipient or amount type combination\".",
+          "scenario": "Schema validation bypassed or stale client",
+          "mitigation": "Use one of the 6 valid pairings: Guard, Entity, or Signer recipient — each with a u8 or u64 amount identifier.",
+          "evidence": "recipient=${first_invalid_pairing_recipient}, amount=${first_invalid_pairing_amount}",
+          "stakeholders": ["owner"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-2-05",
+      "dimension": "semantic",
+      "trigger": "guard_add with a GuardIdentifier recipient slot — the payout address is only as safe as the Guard predicate; owner security due diligence",
+      "cases": [
+        {
+          "when": { "field": "guard_identifier_recipients_display", "op": "truthy" },
+          "level": "medium",
+          "title": "Claim payout address comes from a submission slot — verify the Guard predicate constrains it",
+          "description": "For guard_add entry ${guard_identifier_recipients_display}, the claim recipient is Recipient::GuardIdentifier: claim() reads the payout address from the claim-time passport submission, and claim() itself needs no Permission. Whether that address is legitimate is decided entirely inside the Guard predicate — a guard whose predicate passes without constraining the recipient slot lets any passing party fill the slot with their own address and claim the pool. This is legal by design (the slot CAN be constrained by the predicate), so the safety duty is the configurer's, not the runtime's.",
+          "scenario": "Owner mounts a claim Guard whose root does not bind the submitted recipient (e.g., no Signer/entity constraint)",
+          "mitigation": "1) Review the full Guard definition and confirm the predicate constrains the recipient identifier (e.g., compare it to Signer or to an intended entity address). 2) If the payout should be a fixed party, use an Entity recipient; if it should be the caller, use Signer — neither depends on a submitted slot. 3) Regress on testnet: a claim to an address the predicate does not authorize must be rejected by the guard.",
+          "evidence": "guard_add with GuardIdentifier recipient: [${guard_identifier_recipients_display}]",
+          "stakeholders": ["owner", "service_provider"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "The reward pool is the merchant's deposited budget; a claim Guard that passes without constraining the recipient slot lets the pool drain to arbitrary addresses instead of the intended recipients." }
+            ],
+            "gain_paths": [
+              {
+                "role": "neutral",
+                "path": "A passing party fills the claim-time submission slot with their own address and claims from the pool.",
+                "viability": "conditional",
+                "gate": "Executes only if the Guard predicate fails to bind the submitted recipient — audit the full Guard definition to confirm or block the path."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-3-01",
+      "dimension": "permission",
+      "trigger": "claim attempted without permission context — claim is passport-driven",
+      "cases": [
+        {
+          "when": { "field": "claim", "op": "truthy" },
+          "level": "medium",
+          "title": "claim is permission-free — anyone with a valid Passport can claim",
+          "description": "Claiming does NOT assert any permission index. Eligibility is determined entirely by the Guard verification (the passport guard-result check). If the Guard is too permissive, funds can be drained by anyone.",
+          "scenario": "Loose Guard allows unauthorized claims (e.g. time-only Guard without service binding)",
+          "mitigation": "1) Use Guards that bind to specific Service/Order context. 2) Set expiration_time. 3) Monitor balance and refill only what's needed.",
+          "evidence": "claim=${claim}",
+          "stakeholders": ["owner", "service_provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-3-02",
+      "dimension": "permission",
+      "trigger": "owner_receive (156) — broad blast radius, owner can drain balance",
+      "cases": [
+        {
+          "when": { "field": "owner_receive_set", "op": "eq", "value": true },
+          "level": "high",
+          "title": "owner_receive drains balance to Permission owner",
+          "description": "owner_receive (permission 156) unwraps Receiving<K> / CoinWrapper<K> and forwards to Permission owner. If 156 is granted too broadly, any 156-holder can sweep receivables. (Note: owner_receive does NOT directly drain balance — only Receiving<K> envelopes sent to the Reward's id.)",
+          "scenario": "Compromised 156-holder sweeps receivables before owner",
+          "mitigation": "1) Grant 156 only to the Permission owner address. 2) Reconcile Receiving<K> inflows vs owner_receive events.",
+          "evidence": "owner_receive set",
+          "stakeholders": ["owner", "service_provider"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "Receivables sent to the Reward can be extracted from it by any holder of the drain permission at a time of their choosing, ahead of the owner's own reconciliation." }
+            ],
+            "gain_paths": [
+              {
+                "role": "collaborator",
+                "path": "A 156-holder triggers the unwrap-and-forward drain, extracting Receiving envelopes sent to the Reward out to the Permission owner.",
+                "viability": "conditional",
+                "gate": "The unconfirmed condition is the grant being broader than the owner address; the triggering holder profits only when they control the Permission owner identity the funds route to."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-3-03",
+      "dimension": "permission",
+      "trigger": "Guard-addition time-lock update (155) — can permanently lock guard additions",
+      "cases": [
+        {
+          "when": { "field": "guard_lock_exceeds_year", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "The guard-addition time-lock freezes guard additions for > 1 year",
+          "description": "Setting guard_not_added_expiration_time to ${new_lock_time} (> 1 year from now) effectively freezes the guard list. While this is sometimes intentional (milestone rewards), it cannot be undone without setting a new time (which itself requires 155 permission).",
+          "scenario": "Operator sets excessively long lock period by mistake",
+          "mitigation": "Confirm intent. If wrong, set the guard-addition time-lock again with a shorter time (must be ≥ current clock per E_GUARD_LOCKED_TIME_NOT_INCREASING).",
+          "evidence": "lock_until=${new_lock_time}, clock=${current_clock}",
+          "stakeholders": ["owner"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-4-01",
+      "dimension": "lifecycle",
+      "trigger": "claim on guard with expiration_time < now (E_GUARD_EXPIRED) — catalog stub: the retired check could not inspect guard expiry without a query and always returned null",
+      "cases": [
+        {
+          "when": { "field": "always_true", "op": "eq", "value": false },
+          "level": "info",
+          "title": "claim on guard with expiration_time < now (E_GUARD_EXPIRED)",
+          "description": "Catalog stub — the retired check surfaced no finding: the guard's expiration cannot be inspected at this layer without a query. Retained for catalog completeness; the condition is never satisfiable.",
+          "stakeholders": ["claimer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-4-02",
+      "dimension": "lifecycle",
+      "trigger": "claim: balance < amount (E_INSUFFICIENT_BALANCE)",
+      "cases": [
+        {
+          "when": { "all": [
+            { "field": "claim", "op": "truthy" },
+            { "field": "balance_is_zero", "op": "eq", "value": true }
+          ] },
+          "level": "high",
+          "title": "claim on Reward with zero balance",
+          "description": "Reward balance is 0. Any claim will abort with E_INSUFFICIENT_BALANCE (6). Owner must coin_add (153) or receive (154) to replenish.",
+          "scenario": "Marketing campaign budget exhausted but guards remain active",
+          "mitigation": "1) Owner: coin_add to replenish. 2) Owner: guard_remove ('expired' sweep or the guard ID) + lock guard additions via the time-lock to deactivate. 3) Claimer: wait for replenishment.",
+          "evidence": "balance=0",
+          "stakeholders": ["claimer", "owner"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-4-03",
+      "dimension": "lifecycle",
+      "trigger": "guard_add while guard_not_added_expiration_time is Some and clock ≤ expiration (E_GUARD_LOCKED_TIME)",
+      "cases": [
+        {
+          "when": { "all": [
+            { "field": "guard_add_count", "op": "truthy" },
+            { "field": "guard_add_blocked_by_lock", "op": "eq", "value": true }
+          ] },
+          "level": "high",
+          "title": "guard_add blocked by time-lock (guard_not_added_expiration_time)",
+          "description": "guard_not_added_expiration_time is Some(${lock_until}), clock is ${current_clock}. Move asserts clock > expiration_time (E_GUARD_LOCKED_TIME = 10).",
+          "scenario": "Trying to add guards during a flash sale lock period",
+          "mitigation": "1) Wait until clock > expiration_time. 2) Use the 155-permission time-lock update to extend the lock (cannot shorten below current clock).",
+          "evidence": "lock_until=${lock_until}, clock=${current_clock}",
+          "stakeholders": ["owner"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-4-04",
+      "dimension": "lifecycle",
+      "trigger": "Guard-addition time-lock regression (new time < current clock)",
+      "cases": [
+        {
+          "when": { "field": "lock_time_in_past", "op": "eq", "value": true },
+          "level": "high",
+          "title": "Guard-addition time-lock: new time must be in the future",
+          "description": "New guard_not_added_expiration_time = ${new_lock_time} ≤ clock ${current_clock}. Move aborts with E_GUARD_LOCKED_TIME_INVALID (11).",
+          "scenario": "Operator sets lock time in the past by mistake",
+          "mitigation": "Set guard_expiration_time to a value > ${current_clock} (current clock).",
+          "evidence": "new_time=${new_lock_time}, clock=${current_clock}",
+          "stakeholders": ["owner"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-5-01",
+      "dimension": "cross_object",
+      "trigger": "claim: guard not found in self.guards (E_GUARD_NOT_FOUND)",
+      "cases": [
+        {
+          "when": { "field": "claim_guard_not_in_targets", "op": "eq", "value": true },
+          "level": "high",
+          "title": "claim: supplied guard not in Reward.guards",
+          "description": "Guard ${claim} is not in the Reward's guard list. Move iterates self.guards and aborts with E_GUARD_NOT_FOUND (7) if no match.",
+          "scenario": "Claimer uses the wrong Guard object (typo or wrong Service)",
+          "mitigation": "1) Verify the Guard address via query ObjectReward. 2) Ensure the Guard was added via guard_add (152).",
+          "evidence": "claim_guard=${claim}, known_guards=${known_guards_display}",
+          "stakeholders": ["claimer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-5-02",
+      "dimension": "cross_object",
+      "trigger": "coin_add: coin type T mismatch with Reward<T>",
+      "cases": [
+        {
+          "when": { "field": "coin_type_mismatch", "op": "eq", "value": true },
+          "level": "critical",
+          "title": "coin_add: coin type T mismatch",
+          "description": "Reward is Reward<${reward_type}> but coin_add passes Coin<${coin_type}>. Move type-system mismatch; SDK W_ERROR in operate().",
+          "scenario": "Operator tries to deposit wrong coin type (e.g. USDC into a WOW Reward)",
+          "mitigation": "Use Coin<${reward_type}> for coin_add.",
+          "evidence": "reward_type=${reward_type}, coin_type=${coin_type}",
+          "stakeholders": ["owner"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-5-03",
+      "dimension": "cross_object",
+      "trigger": "receive: Payment<T> type mismatch with Reward<T>",
+      "cases": [
+        {
+          "when": { "field": "payment_token_mismatch", "op": "eq", "value": true },
+          "level": "critical",
+          "title": "receive: Payment token_type mismatch",
+          "description": "Reward is Reward<${reward_type}> but receive's Payment<CoinWrapper<${payment_token_type}>>. SDK W_ERROR in operate().",
+          "scenario": "Operator tries to receive wrong-token Payment",
+          "mitigation": "Use Payment<${reward_type}> for receive.",
+          "evidence": "reward_type=${reward_type}, payment_token=${payment_token_type}",
+          "stakeholders": ["owner"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-6-01",
+      "dimension": "business_semantic",
+      "trigger": "intent mentions praise/positive-review but Guard checks non-wonder progress node",
+      "cases": [
+        {
+          "when": { "field": "praise_intent_wrong_node", "op": "eq", "value": true },
+          "level": "high",
+          "title": "Guard checks progress==\"${expected_progress_state}\" but intent indicates praise reward (wonder node)",
+          "description": "User intent mentions praise/positive-review/wonder, which maps to the 'wonder' progress node (customer gives positive review AFTER service completion). But the Guard's table bakes expected state=\"${expected_progress_state}\", allowing reward claim at the wrong lifecycle stage. This violates the business semantics: \"praise reward\" should only be claimable AFTER the customer advances to the 'wonder' node, not before. Guard is immutable — fixing this requires creating a new Guard + Reward pair.",
+          "scenario": "Designer builds Guard checking 'completed' instead of 'wonder' for a praise reward",
+          "mitigation": "Set the Guard table's expected progress state to 'wonder' (the positive-review node). The correct pattern: ordered → in_service → completed → wonder (praise) triggers reward claim. Reference: reward-templates.ts wonder_praise template.",
+          "evidence": "intent=\"${intent_display}\", expected_state=\"${expected_progress_state}\", expected_wonder=true",
+          "stakeholders": ["owner", "service_provider", "claimer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-6-02",
+      "dimension": "business_semantic",
+      "trigger": "Guard checks wonder node but intent does not mention praise",
+      "cases": [
+        {
+          "when": { "field": "wonder_node_without_praise_intent", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Guard checks wonder node but intent does not mention praise",
+          "description": "Guard's expected progress state is \"wonder\" (positive-review node), but the user intent does not mention any praise/positive-review keyword. This may be a copy-paste from a wonder_praise template without adjusting the Guard for the actual business semantics. If this is a general feedback reward (wonder_feedback), this is fine. Otherwise, verify the node choice.",
+          "scenario": "Designer copies wonder_praise template but actually wants a completion-based reward",
+          "mitigation": "Verify: if intent is praise reward, add 'praise/positive review' to description. If intent is completion-based reward, change Guard to check 'completed' node.",
+          "evidence": "expected_state=\"wonder\", intent=\"${intent_display}\" (no praise keyword)",
+          "stakeholders": ["owner"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-7-01",
+      "dimension": "fund_recovery",
+      "trigger": "coin_add/receive (deposit) or guard_add without an owner fund-recovery escape guard (advisory — recovery via withdraw 158 always exists once the no-guard window lapses)",
+      "cases": [
+        {
+          "when": { "all": [
+            { "field": "recovery_gap_present", "op": "eq", "value": true },
+            { "field": "has_deposit", "op": "eq", "value": true }
+          ] },
+          "level": "medium",
+          "title": "No owner fund-recovery escape guard on this Reward",
+          "description": "claim() is the GUARD-FREE buyer-facing exit from the Reward's balance field, and no configured guard carries the owner claim-side escape signature (Signer recipient + GuardU64Identifier amount). Fund recovery does NOT depend on that signature: withdraw (op 158, ETS-B) is the second exit — permission-gated and blocked ONLY while the no-guard window (guard_not_added_expiration_time) stands; once it lapses (or if it was never set) the owner recovers the full unclaimed remainder (guard_expiration_time_add can set/clear the window after it expires). An unclaimed remainder is therefore NEVER permanently locked. The escape guard is an OPTIONAL in-window recovery rail (owner reclaims via claim() behind a Clock lock) or a one-PTB alternative — its absence is an advisory configuration note, not a fund-safety defect. Note: owner_receive (op 156) never touches balance — it only extracts objects the Reward RECEIVED via transfer (Receiving<CoinWrapper<K>> or NFT-like objects) to the Permission owner; receive (op 154) is what joins payments into balance.",
+          "scenario": "A marketing Reward is fully consumed by guards, the campaign ends with a residual balance, and the merchant has no guard that lets them reclaim it.",
+          "mitigation": "PRIMARY (no guard needed): after guard_not_added_expiration_time lapses — or immediately if it was never set — call withdraw (op 158) / withdraw_and_unwrap to recover the unclaimed remainder in full (payment.receipt or same-PTB unwrap). OPTIONAL in-window escape guard: (1) Guard: logic_and(logic_equal(query(1002 permission.owner [permission_address]), Signer), logic_greater_equal(Clock, <unlock_time>)) — verifies the tx sender is the live Permission owner, with the Clock comparison acting as the lock period (e.g. 30 days); (2) RewardGuard entry: recipient=Signer, amount=GuardU64Identifier(u8 submission mark), expiration_time=unlock_time + claim window (or None) — remember the contract asserts clock <= expiration_time, i.e. expiration is the last claimable moment, not the unlock moment; (3) after unlock the owner claims by submitting the full remaining balance.",
+          "evidence": "deposit=${has_deposit}, guard_add=${guard_add_count}, escape=false (no entry with Signer recipient + GuardU64Identifier amount)",
+          "stakeholders": ["owner"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "Residual budget stays committed (unwithdrawable) only until guard_not_added_expiration_time lapses; recoverable in full thereafter via withdraw (op 158). Advisory only: the escape guard adds IN-WINDOW owner recovery." }
+            ],
+            "gain_paths": []
+          }
+        },
+        {
+          "when": { "field": "recovery_gap_present", "op": "eq", "value": true },
+          "level": "low",
+          "title": "No owner fund-recovery escape guard on this Reward",
+          "description": "claim() is the GUARD-FREE buyer-facing exit from the Reward's balance field, and no configured guard carries the owner claim-side escape signature (Signer recipient + GuardU64Identifier amount). Fund recovery does NOT depend on that signature: withdraw (op 158, ETS-B) is the second exit — permission-gated and blocked ONLY while the no-guard window (guard_not_added_expiration_time) stands; once it lapses (or if it was never set) the owner recovers the full unclaimed remainder (guard_expiration_time_add can set/clear the window after it expires). An unclaimed remainder is therefore NEVER permanently locked. The escape guard is an OPTIONAL in-window recovery rail (owner reclaims via claim() behind a Clock lock) or a one-PTB alternative — its absence is an advisory configuration note, not a fund-safety defect. Note: owner_receive (op 156) never touches balance — it only extracts objects the Reward RECEIVED via transfer (Receiving<CoinWrapper<K>> or NFT-like objects) to the Permission owner; receive (op 154) is what joins payments into balance.",
+          "scenario": "A marketing Reward is fully consumed by guards, the campaign ends with a residual balance, and the merchant has no guard that lets them reclaim it.",
+          "mitigation": "PRIMARY (no guard needed): after guard_not_added_expiration_time lapses — or immediately if it was never set — call withdraw (op 158) / withdraw_and_unwrap to recover the unclaimed remainder in full (payment.receipt or same-PTB unwrap). OPTIONAL in-window escape guard: (1) Guard: logic_and(logic_equal(query(1002 permission.owner [permission_address]), Signer), logic_greater_equal(Clock, <unlock_time>)) — verifies the tx sender is the live Permission owner, with the Clock comparison acting as the lock period (e.g. 30 days); (2) RewardGuard entry: recipient=Signer, amount=GuardU64Identifier(u8 submission mark), expiration_time=unlock_time + claim window (or None) — remember the contract asserts clock <= expiration_time, i.e. expiration is the last claimable moment, not the unlock moment; (3) after unlock the owner claims by submitting the full remaining balance.",
+          "evidence": "deposit=${has_deposit}, guard_add=${guard_add_count}, escape=false (no entry with Signer recipient + GuardU64Identifier amount)",
+          "stakeholders": ["owner"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "Residual budget stays committed (unwithdrawable) only until guard_not_added_expiration_time lapses; recoverable in full thereafter via withdraw (op 158). Advisory only: the escape guard adds IN-WINDOW owner recovery." }
+            ],
+            "gain_paths": []
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-8-01",
+      "dimension": "business_semantic",
+      "trigger": "experience-compensation intent with guards being configured — pool solvency disclosure (claims > balance abort, non-escrow, no per-claim isolation)",
+      "cases": [
+        {
+          "when": { "all": [
+            { "field": "compensation_intent", "op": "eq", "value": true },
+            { "field": "guard_add_count", "op": "truthy" }
+          ] },
+          "level": "medium",
+          "title": "Compensation pool solvency: the pool is NOT per-order escrow — claims beyond the balance abort",
+          "description": "Experience compensation rides the Reward object (C-11): one pre-funded pool serves ALL buyers' claims, with no per-order isolation. A claim larger than the current balance aborts with E_INSUFFICIENT_BALANCE (6) — the buyer faces a failed claim, not a queued payout. Size coin_add to expected claims × worst tier and refill on schedule; the residual stays recoverable via withdraw (op 158) after the no-guard window lapses (R-R-7-01).",
+          "scenario": "A late-delivery wave drains the compensation pool before the tail of the wave claims",
+          "mitigation": "1) Fund upfront for the worst-case claim wave (expected claims × worst tier), refill periodically. 2) Keep tiers so a single claim cannot exceed a bounded share of the pool. 3) Monitor the balance against the open claim window — an exhausted pool turns the compensation promise into an unfunded one (must be disclosed, never silently left to abort).",
+          "evidence": "compensation intent, guard_add=${guard_add_count}",
+          "stakeholders": ["owner", "service_provider", "claimer"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "A claim beyond the pool balance aborts (E_INSUFFICIENT_BALANCE) — the buyer holds a compensation promise that does not pay." }
+            ],
+            "gain_paths": []
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-8-02",
+      "dimension": "business_semantic",
+      "trigger": "experience-compensation intent — the merchant's withdraw (158) right makes the funding commitment reversible",
+      "cases": [
+        {
+          "when": { "field": "compensation_intent", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Compensation funding is reversible — the owner can withdraw the unclaimed remainder (permission 158)",
+          "description": "withdraw (158) is the only non-claim exit from the Reward balance. It is blocked while the no-guard window (guard_not_added_expiration_time) stands — setting that window IS the public funding commitment — and unblocked once it lapses, letting the owner pull the unclaimed remainder inside a Payment receipt. A compensation promise is therefore time-bounded by construction; the withdrawal right and window MUST be disclosed (reversibility), never implied to be perpetual.",
+          "scenario": "A merchant withdraws the compensation pool right after the no-guard window lapses, before slow claimers act",
+          "mitigation": "1) Disclose the no-guard window and the post-window withdrawal right in the listing. 2) Size the window to cover realistic claim latency. 3) Buyers: treat an expired no-guard window as the pool's commitment horizon — claims after it may find an empty pool by design.",
+          "evidence": "compensation intent",
+          "stakeholders": ["owner", "claimer"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "After the no-guard window lapses the owner can withdraw the unclaimed balance; a late claim can find an empty pool." }
+            ],
+            "gain_paths": [
+              {
+                "role": "merchant",
+                "path": "The owner withdraws the unclaimed remainder once the declared no-guard window has elapsed.",
+                "viability": "viable",
+                "gate": "Legal by design (permission 158; E_GUARD_LOCKED_TIME only blocks while the window stands) — the commitment is reversible; disclosure is the obligation."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-8-03",
+      "dimension": "business_semantic",
+      "trigger": "experience-compensation intent — claims are user-initiated, so realized payouts undershoot the pool by design",
+      "cases": [
+        {
+          "when": { "field": "compensation_intent", "op": "eq", "value": true },
+          "level": "info",
+          "title": "Claim friction is a design property: the realized compensation rate is < 100% unless buyers claim",
+          "description": "Reward compensation pays ONLY on an explicit claim (passport-driven, no push path). A claim rate below 100% is the DESIGN EXPECTATION, not a defect — but the merchant must not present the pool as automatic indemnity, and the buyer must know the payout requires an active claim inside the window.",
+          "scenario": "A merchant advertises 'guaranteed late compensation' while the claim rail needs each buyer to transact",
+          "mitigation": "1) Phrase the promise as claimable, not automatic. 2) Publish the claim window and how to claim (guard + submission slots). 3) Do not book goodwill on the full pool — only claimed amounts leave it.",
+          "evidence": "compensation intent",
+          "stakeholders": ["owner", "claimer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-8-04",
+      "dimension": "business_semantic",
+      "trigger": "experience-compensation intent with a GuardU64Identifier amount — the claim amount is submission-computed, not on-chain clamped",
+      "cases": [
+        {
+          "when": { "all": [
+            { "field": "compensation_intent", "op": "eq", "value": true },
+            { "field": "has_identifier_amount", "op": "eq", "value": true }
+          ] },
+          "level": "medium",
+          "title": "Dynamic compensation amount: the claim-time value is computed by the submitting party, not clamped on-chain",
+          "description": "Amount::GuardU64Identifier resolves the claim amount from the claimer's Passport submission slot at claim time. The chain only type-checks the slot (u64; E_AMOUNT_NOT_U64 (5) at construction) — the VALUE is whatever the submitting party computed from the tier rule. 'The later, the more' compensation expressed this way is data-driven trust: the tier computation rule MUST be disclosed, and the pool balance (R-R-8-01) remains the real ceiling.",
+          "scenario": "A tiered late-compensation guard whose submission amount is computed by the merchant's claim tooling",
+          "mitigation": "1) Disclose the exact tier formula in the listing (minutes late → amount). 2) Keep the computation deterministic and auditable (repository evidence rows help). 3) Prefer Fixed tiers where the rule is simple — the on-chain value is then the whole promise.",
+          "evidence": "compensation intent, dynamic amount present",
+          "stakeholders": ["owner", "claimer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-R-8-05",
+      "dimension": "business_semantic",
+      "trigger": "experience-compensation intent with a deposit — the pool outflow is one-way, claimed funds are never clawed back",
+      "cases": [
+        {
+          "when": { "all": [
+            { "field": "compensation_intent", "op": "eq", "value": true },
+            { "field": "has_deposit", "op": "eq", "value": true }
+          ] },
+          "level": "low",
+          "title": "No clawback: compensation flows one way — out to claimers",
+          "description": "The Reward balance has no pull-back path for PAID claims: claim (guard-free) and withdraw (158) both move funds OUT; the UNCLAIMED remainder is recoverable via withdraw (158) once the no-guard window (guard_not_added_expiration_time) lapses — or in-window via the R-R-7-01 escape guard. A paid claim is final even if the underlying incident is later reversed (e.g. the order is refunded after an overlapping-window compensation claim) — supplier recourse is a SEPARATE ledger (off-chain or a distinct on-chain arrangement), never a Reward-side reversal.",
+          "scenario": "A buyer claims late-compensation and then also wins a refund; the merchant wants the compensation back",
+          "mitigation": "1) Prevent overlap structurally: the compensation guard accepts completed/settled terminals only (tbs7 F-04 claim-and-return precedent). 2) Treat paid compensation as sunk; recover from the supplier through the separate recourse arrangement. 3) Recover the unclaimed tail via withdraw (158) after the no-guard window lapses; the escape guard (R-R-7-01) is the in-window alternative.",
+          "evidence": "compensation intent, deposit=${has_deposit}",
+          "stakeholders": ["owner", "service_provider"]
+        }
+      ]
+    }
+  ]
+}