@wowok/agent-mcp 3.1.2 → 3.1.4

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

@@ -0,0 +1,117 @@
+{
+  "comment": "Resource rule pack (R-RESOURCE) — declarative form of the retired in-code Resource risk rules. Facts are produced by the kernel extractor (resource-risk.ts, bound to the on-chain tag limit); 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": {
+    "expects_resource_permission": "The caller relies on Resource enforcing its own permission checks (it associates none — access control is delegated to the calling module).",
+    "expects_tag_events": "The caller expects tag mutations to emit on-chain events (tag operations emit none — indexers must poll).",
+    "tags_count": "Raw tag count for a single object, passed through for evidence text.",
+    "tags_count_over_limit": "True when tags_count is provided and meets or exceeds the chain tag limit (the on-chain abort boundary).",
+    "is_destroy": "The caller is invoking the irreversible destroy operation.",
+    "tag_set_return_ignored": "The caller discards the bool result of the tag-set operation (the 'already exists' signal).",
+    "references_dead_switch": "The caller references the fully commented-out (dead) switch function of the Move layer.",
+    "max_tags_count": "KERNEL CONSTANT — maximum tag entries a single object's tag vector may hold (the on-chain abort boundary)."
+  },
+  "rules": [
+    {
+      "rule_id": "R-RESOURCE-01",
+      "dimension": "permission",
+      "trigger": "caller relies on Resource enforcing its own permission checks",
+      "cases": [
+        {
+          "when": { "field": "expects_resource_permission", "op": "eq", "value": true },
+          "level": "low",
+          "title": "Resource has no Permission — relies entirely on caller-side gating",
+          "description": "Resource does not associate with a Permission object. All functions are public(package) (new/destroy/transfer) or public (tag set/unset, object tag add/remove, object removal) — there is no on-chain permission check. Access control is delegated to the calling module (Personal, Entity). A caller that forgets to enforce its own permission check would let any address mutate tags.",
+          "scenario": "Personal/Entity forgets to gate object-tag additions behind its own permission check",
+          "mitigation": "Callers (Personal, Entity) MUST enforce their own permission checks before invoking Resource functions. Audit the call sites in Personal/Entity to confirm gating.",
+          "evidence": "expects_resource_permission=true (Resource has none)",
+          "stakeholders": ["owner", "caller"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-RESOURCE-02",
+      "dimension": "semantic",
+      "trigger": "caller expects tag mutations to emit events",
+      "cases": [
+        {
+          "when": { "field": "expects_tag_events", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Tag mutations emit no events — external indexers must poll",
+          "description": "Object-tag additions, object-tag removals, and whole-object removals do not emit events. External indexers cannot rely on an event stream to track tag changes; they must poll the ParentTable field. This complicates real-time notification and consistency.",
+          "scenario": "Indexer expects a TagAddedEvent but none is emitted; UI fails to refresh",
+          "mitigation": "External indexers should poll Resource.table on a cadence. Do not build critical UX on tag event streams until events are added in a future version.",
+          "evidence": "expects_tag_events=true (no events emitted)",
+          "stakeholders": ["owner", "caller"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-RESOURCE-03",
+      "dimension": "structural",
+      "trigger": "tag count meets or exceeds the chain tag limit",
+      "cases": [
+        {
+          "when": { "field": "tags_count_over_limit", "op": "eq", "value": true },
+          "level": "low",
+          "title": "MAX_TAGS_COUNT=${max_tags_count} permissive — storage cost",
+          "description": "A single object's AddressTag.tags vector may hold up to MAX_TAGS_COUNT=${max_tags_count} entries. The limit aborts with E_TAGS_COUNT_EXCEEDED (1) only at the boundary. 100 tags per object is generous; loading all tags on every read increases gas and storage cost.",
+          "scenario": "Caller adds 100 tags to a single object",
+          "mitigation": "Business layer should self-limit tag count well below 100. For heavy tagging, shard across multiple Resource objects or store bulk tags off-chain.",
+          "evidence": "tags_count=${tags_count}, limit=${max_tags_count}",
+          "stakeholders": ["owner"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-RESOURCE-04",
+      "dimension": "lifecycle",
+      "trigger": "destroy is being invoked",
+      "cases": [
+        {
+          "when": { "field": "is_destroy", "op": "eq", "value": true },
+          "level": "low",
+          "title": "destroy is irreversible — no recovery mechanism",
+          "description": "Resource.destroy(resource) deletes the object and its ParentTable in place. There is no archive, no event, and no rollback. Once destroyed, the object ID is permanently invalid and all tags are lost.",
+          "scenario": "Caller destroys a Resource that is still referenced by Personal/Entity",
+          "mitigation": "Confirm no live references exist before calling destroy. SDK should refuse to destroy a Resource whose owner address is still referenced by Personal.mark or Entity.resource.",
+          "evidence": "is_destroy=true (irreversible)",
+          "stakeholders": ["owner"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-RESOURCE-05",
+      "dimension": "semantic",
+      "trigger": "tag-set bool return value is ignored by the caller",
+      "cases": [
+        {
+          "when": { "field": "tag_set_return_ignored", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Setting a tag returns bool — SDK may ignore the 'already exists' signal",
+          "description": "Setting a tag on an object returns bool: true if a new tag was added, false if the tag already existed. If the SDK ignores the return value, callers cannot distinguish 'newly added' from 'duplicate silently skipped'. This masks intent and complicates idempotency reasoning.",
+          "scenario": "SDK treats the tag-set result as void; caller assumes tag was added when it was a duplicate",
+          "mitigation": "SDK should expose the tag-set bool return value to the caller. UI should show 'tag already existed' when false is returned.",
+          "evidence": "tag_set_return_ignored=true (duplicate not surfaced)",
+          "stakeholders": ["caller"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-RESOURCE-06",
+      "dimension": "semantic",
+      "trigger": "caller references the commented-out switch function",
+      "cases": [
+        {
+          "when": { "field": "references_dead_switch", "op": "eq", "value": true },
+          "level": "low",
+          "title": "Commented-out switch function — feature may be intended",
+          "description": "The module contains a switch function that is fully commented out. The intended behavior is unclear — it may be a planned feature (e.g. bulk tag operations) that was disabled. Referencing it as if it were live would silently fail.",
+          "scenario": "Developer reads the commented switch and assumes it is callable",
+          "mitigation": "Confirm with the package maintainers whether the switch should be enabled or removed. Do not reference it in SDK or MCP code.",
+          "evidence": "references_dead_switch=true (commented out in Move)",
+          "stakeholders": ["system"]
+        }
+      ]
+    }
+  ]
+}

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

@@ -0,0 +1,471 @@
+{
+  "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. 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).",
+    "has_deposit": "The operation deposits (coin_add or receive present).",
+    "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 + 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",
+      "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 ONLY exit from the Reward's balance field, and none of the guards being configured is an owner escape hatch — any unclaimed remainder stays locked forever. Note: owner_receive (op 156) does NOT help here: it only extracts objects the Reward RECEIVED via transfer (Receiving<CoinWrapper<K>> or NFT-like objects) to the Permission owner and never touches balance; receive (op 154) is what joins payments into balance. This is a configuration gap, not a contract defect.",
+          "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": "Add an escape guard alongside the other guards: (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 to recover 100%.",
+          "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": "Unclaimed reward remainder stays locked in the balance field forever — the merchant's deposited budget is unrecoverable." }
+            ],
+            "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 ONLY exit from the Reward's balance field, and none of the guards being configured is an owner escape hatch — any unclaimed remainder stays locked forever. Note: owner_receive (op 156) does NOT help here: it only extracts objects the Reward RECEIVED via transfer (Receiving<CoinWrapper<K>> or NFT-like objects) to the Permission owner and never touches balance; receive (op 154) is what joins payments into balance. This is a configuration gap, not a contract defect.",
+          "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": "Add an escape guard alongside the other guards: (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 to recover 100%.",
+          "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": "Unclaimed reward remainder stays locked in the balance field forever — the merchant's deposited budget is unrecoverable." }
+            ],
+            "gain_paths": []
+          }
+        }
+      ]
+    }
+  ]
+}