@wowok/agent-mcp 3.1.3 → 3.1.5

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

@@ -0,0 +1,197 @@
+{
+  "comment": "Bridge rule pack (R-BRIDGE) — declarative form of the retired in-code Bridge risk rules. Facts are produced by the kernel extractor (bridge-risk.ts, bound to the bridge constants and the idempotency bound); 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": {
+    "assumes_committee_infallible": "The caller assumes committee signatures cannot be forged (they are the single trust root for cross-chain message verification).",
+    "is_non_mainnet": "The caller is operating on a non-mainnet environment (the Bridge role is configured on mainnet only).",
+    "transfer_amount": "Transfer amount in base units, provided for limiter heuristics.",
+    "assumes_per_user_evm_account": "The caller assumes activeEvmAccount is per-user (it is a single global account, transparent to users).",
+    "uses_public_evm_rpc": "The caller uses a public EVM RPC endpoint (frequent HTTP 429 rate-limit risk).",
+    "is_paused": "The Bridge is currently paused (EmergencyOp) — cross-chain operations stall and in-flight assets cannot be claimed.",
+    "unsupported_token": "The token symbol the caller attempts to bridge (must be one of the supported tokens).",
+    "idempotency_key_length": "Length of the idempotency key the caller generates (on-chain bound: 1..128 chars).",
+    "expects_simple_error_codes": "The caller is debugging and expects a small error-code surface (the bridge defines 20 numeric abort codes).",
+    "versioned_upgrade_in_progress": "A Versioned schema upgrade of the Bridge package is in progress (inner-version migration risk).",
+    "constants_synced": "Whether the Bridge constants are synced to onchain-constants.ts.",
+    "idempotency_key_over_limit": "KERNEL — the submitted idempotency key length exceeds the live on-chain bound (max_idempotency_key_length).",
+    "supported_token_count": "KERNEL CONSTANT — number of tokens the bridge supports.",
+    "supported_tokens_display": "KERNEL CONSTANT — the supported token symbols, comma-space separated (display form).",
+    "supported_tokens_csv": "KERNEL CONSTANT — the supported token symbols, comma separated (compact form).",
+    "max_idempotency_key_length": "KERNEL CONSTANT — maximum idempotency key length accepted by the bridge (128).",
+    "error_code_count": "KERNEL CONSTANT — number of numeric abort codes the bridge defines (20).",
+    "bridge_message_version": "KERNEL CONSTANT — live BRIDGE_MESSAGE_VERSION from the published package.",
+    "bridge_current_version": "KERNEL CONSTANT — live BRIDGE_CURRENT_VERSION of the Versioned wrapper.",
+    "bridge_evm_address_length": "KERNEL CONSTANT — live BRIDGE_EVM_ADDRESS_LENGTH in bytes.",
+    "always_true": "Always true — marks the unconditional informational rule (the TransferLimiter reminder fires for every transfer scenario)."
+  },
+  "rules": [
+    {
+      "rule_id": "R-BRIDGE-01",
+      "dimension": "permission",
+      "trigger": "caller assumes committee signatures cannot be forged",
+      "cases": [
+        {
+          "when": { "field": "assumes_committee_infallible", "op": "eq", "value": true },
+          "level": "critical",
+          "title": "Cross-chain asset security — committee signature verification is the single trust root",
+          "description": "Bridge committee signatures are the only thing preventing forged cross-chain messages from minting tokens out of thin air. If a committee key is compromised, or if the verification logic has a bug, an attacker can claim arbitrary amounts of ETH/WETH/WBTC/USDC/USDT. The TransferLimiter caps single-transfer amounts but does not prevent repeated small attacks.",
+          "scenario": "Committee private key leaks; attacker forges an approved transfer and claims funds",
+          "mitigation": "Committee members MUST use HSM-backed multi-sig. Rotate keys on a schedule. Audit committee membership and signature verification logic on every release. Monitor limiter utilization for suspicious patterns. Have an EmergencyOp pause plan ready.",
+          "evidence": "assumes_committee_infallible=true (trust root is single-point)",
+          "stakeholders": ["user", "committee", "system"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-BRIDGE-02",
+      "dimension": "cross_object",
+      "trigger": "caller operates on a non-mainnet environment",
+      "cases": [
+        {
+          "when": { "field": "is_non_mainnet", "op": "eq", "value": true },
+          "level": "high",
+          "title": "Bridge is mainnet-only — testnet operations will fail",
+          "description": "The Bridge is only configured on mainnet. testnet nodes do not have the bridge role configured, so any cross-chain operation (cross_chain_wow_to_evm, cross_chain_evm_to_wow, claim_wow_to_evm, etc.) will abort. Developers who test on testnet will see EBridgeUnavailable (8) and may misdiagnose it as a code bug.",
+          "scenario": "Developer runs cross_chain_wow_to_evm on testnet; aborts with EBridgeUnavailable",
+          "mitigation": "MCP layer MUST validate mainnet environment before submitting Bridge ops. Document the mainnet-only restriction prominently. For testing, use mainnet small-amount transactions or fork tests.",
+          "evidence": "is_non_mainnet=true (Bridge unavailable)",
+          "stakeholders": ["user", "operator"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-BRIDGE-04",
+      "dimension": "permission",
+      "trigger": "caller assumes activeEvmAccount is per-user",
+      "cases": [
+        {
+          "when": { "field": "assumes_per_user_evm_account", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "activeEvmAccount is a single global EVM account — key leak affects all assets",
+          "description": "Bridge uses a single global activeEvmAccount that is auto-generated and transparent to users. All cross-chain EVM-side operations flow through this one account. If its private key leaks, every supported token (ETH/WETH/WBTC/USDC/USDT) on every supported chain is at risk. There is no per-user EVM account isolation.",
+          "scenario": "activeEvmAccount private key leaks; attacker drains all bridged EVM assets",
+          "mitigation": "Store the activeEvmAccount key in an HSM. Rotate the key on a schedule and via Versioned upgrade. Monitor EVM-side balances for anomalous outflows. Have an EmergencyOp pause plan ready.",
+          "evidence": "assumes_per_user_evm_account=true (it is global)",
+          "stakeholders": ["user", "system"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-BRIDGE-05",
+      "dimension": "cross_object",
+      "trigger": "caller uses a public EVM RPC endpoint",
+      "cases": [
+        {
+          "when": { "field": "uses_public_evm_rpc", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Public EVM RPCs may rate-limit (HTTP 429) — cross-chain ops stall",
+          "description": "Bridge ops that query EVM state (query_active_evm_account, query_supported_evm_chains, query_transfer_status, etc.) depend on an EVM RPC. Public RPCs (e.g. Infura free tier, Alchemy free tier) frequently return HTTP 429 under load. A 429 mid-flow stalls the cross-chain operation and may confuse the user. manage_evm_rpc supports multi-RPC rotation, but it must be configured in advance.",
+          "scenario": "User queries transfer status; public RPC returns 429; UI shows generic error",
+          "mitigation": "Configure multiple EVM RPCs via manage_evm_rpc and enable failover. Use a paid RPC tier for production. Surface 429 as 'RPC busy, retry' rather than 'operation failed'.",
+          "evidence": "uses_public_evm_rpc=true (429 risk)",
+          "stakeholders": ["user", "operator"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-BRIDGE-06",
+      "dimension": "lifecycle",
+      "trigger": "the Bridge is currently paused",
+      "cases": [
+        {
+          "when": { "field": "is_paused", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "EmergencyOp can pause the Bridge — assets lock during pause",
+          "description": "EmergencyOp can pause the entire Bridge. While paused, no cross-chain operations proceed — assets in flight cannot be claimed, new transfers cannot be initiated. The pause is intended for incident response, but a prolonged pause locks user funds for the duration.",
+          "scenario": "Bridge is paused for incident response; users cannot claim in-flight transfers",
+          "mitigation": "Document the pause scenario and the emergency plan. Provide a status page showing pause state. Set expectations on pause duration and recovery. Operators should practice un-pause drills.",
+          "evidence": "is_paused=true (assets locked)",
+          "stakeholders": ["user", "operator"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-BRIDGE-07",
+      "dimension": "structural",
+      "trigger": "caller attempts to bridge a token outside the supported list",
+      "cases": [
+        {
+          "when": { "field": "unsupported_token", "op": "truthy" },
+          "level": "low",
+          "title": "Only ${supported_token_count} tokens supported — unsupported tokens cannot bridge",
+          "description": "Bridge supports exactly ${supported_token_count} tokens: ${supported_tokens_display}. Any other token (e.g. DAI, LINK, custom tokens) cannot be bridged. Users holding unsupported tokens will see their transfer rejected with EUnexpectedTokenType (3).",
+          "scenario": "User attempts to bridge DAI; aborts with EUnexpectedTokenType",
+          "mitigation": "Document the supported token list prominently. UI should filter the token picker to supported tokens only. For unsupported tokens, recommend an alternative bridge.",
+          "evidence": "unsupported_token=${unsupported_token} (supported: ${supported_tokens_csv})",
+          "stakeholders": ["user"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-BRIDGE-08",
+      "dimension": "structural",
+      "trigger": "idempotency key length exceeds the on-chain bound (128)",
+      "cases": [
+        {
+          "when": { "field": "idempotency_key_over_limit", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Idempotency key max ${max_idempotency_key_length} chars — long keys truncate or reject",
+          "description": "BridgeIdempotencyKeySchema accepts strings of length 1-${max_idempotency_key_length}. Callers who generate idempotency keys from long sources (e.g. full JSON payloads, UUIDs with prefixes) may exceed the limit and see the operation rejected. The limit exists to keep on-chain storage bounded.",
+          "scenario": "Caller uses a 200-char idempotency key; operation rejected",
+          "mitigation": "Generate idempotency keys from a hash (e.g. keccak256 of the payload, hex-encoded = 66 chars) or a UUID (36 chars). Validate length client-side before submission.",
+          "evidence": "idempotency_key_length=${idempotency_key_length}, limit=${max_idempotency_key_length}",
+          "stakeholders": ["user"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-BRIDGE-09",
+      "dimension": "structural",
+      "trigger": "caller is debugging and expects a small error-code surface",
+      "cases": [
+        {
+          "when": { "field": "expects_simple_error_codes", "op": "eq", "value": true },
+          "level": "low",
+          "title": "${error_code_count} error codes — debugging requires a lookup table",
+          "description": "Bridge defines ${error_code_count} error codes (EUnexpectedMessageType=0 through ETokenValueIsZero=19). Debugging an abort requires mapping the numeric code back to its name and meaning. New contributors often misread codes because they are not enumerated in the abort message.",
+          "scenario": "Bridge aborts with code 15; developer does not know what ETokenAlreadyClaimedOrHitLimit means",
+          "mitigation": "Publish an error-code lookup table in the docs. SDK should decode abort codes into human-readable strings. MCP layer should surface the decoded name in error messages.",
+          "evidence": "expects_simple_error_codes=true (there are ${error_code_count})",
+          "stakeholders": ["user", "operator"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-BRIDGE-10",
+      "dimension": "lifecycle",
+      "trigger": "a Versioned schema upgrade of the Bridge is in progress",
+      "cases": [
+        {
+          "when": { "field": "versioned_upgrade_in_progress", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Versioned upgrade (current=${bridge_current_version}) can brick the Bridge if botched",
+          "description": "Bridge uses Versioned to wrap BridgeInner, supporting schema upgrades. The current version is BRIDGE_CURRENT_VERSION=${bridge_current_version}. An upgrade that mishandles the inner version migration can permanently brick the Bridge — funds in flight would be locked, and recovery requires a new package version. The message_version (current=${bridge_message_version}) and EVM address length (${bridge_evm_address_length} bytes) are also versioned.",
+          "scenario": "Upgrade mishandles BridgeInner migration; Bridge becomes unusable",
+          "mitigation": "Test upgrades on a fork with full state replay. Keep a rollback package version ready. Stage upgrades with a pause window so users can complete in-flight ops. Audit message_version and EVM address length compatibility on every upgrade.",
+          "evidence": "versioned_upgrade_in_progress=true (current=${bridge_current_version})",
+          "stakeholders": ["user", "operator", "system"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-BRIDGE-03",
+      "dimension": "structural",
+      "trigger": "any transfer scenario (unconditional informational limiter reminder)",
+      "cases": [
+        {
+          "when": { "field": "always_true", "op": "eq", "value": true },
+          "level": "high",
+          "title": "TransferLimiter caps single and cumulative transfer amounts — large transfers reject",
+          "description": "The TransferLimiter enforces both per-transfer and cumulative transfer caps per token type. A transfer that exceeds the cap aborts with ETokenAlreadyClaimedOrHitLimit (15) or similar. Users attempting large cross-chain moves will see their transactions rejected and may misdiagnose it as a bug.",
+          "scenario": "User attempts to bridge 1000 ETH; limiter rejects the transfer",
+          "mitigation": "Document the limiter semantics. Before submitting, query the current limiter utilization. For large amounts, split into batches across multiple transactions and/or time windows. Surface the remaining cap in the UI.",
+          "stakeholders": ["user"]
+        }
+      ]
+    }
+  ]
+}

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

@@ -0,0 +1,152 @@
+{
+  "comment": "Contact rule pack (R-CONTACT) — declarative form of the retired in-code Contact risk rules. Facts are produced by the kernel extractor (contact-risk.ts, bound to the on-chain IM roster 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. R-CONTACT-03 stays LAST in the array: it is the unconditional no-events reminder the retired check appended after every evaluation.",
+  "facts": {
+    "im_count": "Raw IM entry count for a single Contact, passed through for evidence text.",
+    "im_count_over_limit": "True when im_count is provided and meets or exceeds the chain IM roster limit.",
+    "change_status_no_permission": "The status self-update is invoked without a Permission check (any IM member may rewrite their status string).",
+    "location_empty": "The location field is the empty-string default (indistinguishable from 'unset').",
+    "im_add_description_uses_long_name": "The IM-entry description is validated with the LONG_NAME validator instead of DESCRIPTION (different length cap).",
+    "bound_to_permission_um": "The Contact is bound as a Permission's um (bidirectional dependency; deletion requires unbinding first).",
+    "my_status_from_non_member": "The status self-update is invoked by an address not in the ims list (silently ignored on-chain).",
+    "constants_synced": "True when the contact constants are in sync with the published chain constants (false = knowledge-layer regression).",
+    "always_true": "Unconditional marker fact — rules that fire for every evaluation reference it.",
+    "max_im_count": "KERNEL CONSTANT — maximum IM entries a single Contact may hold."
+  },
+  "rules": [
+    {
+      "rule_id": "R-CONTACT-01",
+      "dimension": "permission",
+      "trigger": "status self-update invoked without a Permission check",
+      "cases": [
+        {
+          "when": { "field": "change_status_no_permission", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "IM member status self-update has no permission check — IM list pollution risk",
+          "description": "The status self-update lets any IM member rewrite their status string without Permission verification. If an attacker's address is added to the ims list (an operation gated by permission index 453), the attacker can freely pollute their status field (e.g. set status to 'fraud'). The risk is bounded by the permission gate on adding IM entries, but a misconfigured Permission could expose the IM list.",
+          "scenario": "Contact's IM list is misconfigured to allow public adds; attacker pollutes status",
+          "mitigation": "Restrict permission index 453 (CONTACT_IM) to trusted guardians. Audit the IM list periodically. Business layer may validate status strings against an allowlist.",
+          "evidence": "change_status_no_permission=true",
+          "stakeholders": ["creator", "im_member"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-CONTACT-02",
+      "dimension": "structural",
+      "trigger": "IM roster count meets or exceeds the chain limit",
+      "cases": [
+        {
+          "when": { "field": "im_count_over_limit", "op": "eq", "value": true },
+          "level": "low",
+          "title": "MAX_IM_COUNT=${max_im_count} is permissive — on-chain storage cost",
+          "description": "A single Contact may hold up to MAX_IM_COUNT=${max_im_count} IM entries. Aborting with E_IM_COUNT_EXCEEDED (1) only triggers at the boundary. 200 entries is relatively permissive for a social scenario; loading the full list on every read increases gas and storage cost.",
+          "scenario": "Caller adds 200 IM entries to a single Contact",
+          "mitigation": "Business layer should self-limit IM count well below 200. For high-volume contact lists, shard across multiple Contact objects and aggregate off-chain.",
+          "evidence": "im_count=${im_count}, limit=${max_im_count}",
+          "stakeholders": ["creator"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-CONTACT-04",
+      "dimension": "semantic",
+      "trigger": "location field left at the empty-string default",
+      "cases": [
+        {
+          "when": { "field": "location_empty", "op": "eq", "value": true },
+          "level": "low",
+          "title": "location defaults to empty string — may be misread as 'unset'",
+          "description": "A freshly created Contact has location=\"\" (empty String). The Move type does not distinguish 'unset' from 'empty', so consumers may misinterpret an empty location as 'globally applicable' or as 'missing data'.",
+          "scenario": "Consumer reads location=\"\" and treats the Contact as global when it was never set",
+          "mitigation": "Document that empty location means 'not specified'. If a default region is required, set location explicitly at creation time.",
+          "evidence": "location=\"\" (empty, default)",
+          "stakeholders": ["creator", "consumer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-CONTACT-05",
+      "dimension": "lifecycle",
+      "trigger": "status self-update invoked by a non-IM-member",
+      "cases": [
+        {
+          "when": { "field": "my_status_from_non_member", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "my_status silently fails for non-IM-members",
+          "description": "my_status only updates the caller's status entry if the caller is in the ims list. For a non-IM-member, the call silently succeeds without any state change — there is no abort and no event. Users get no feedback, making it impossible to distinguish 'status updated' from 'operation ignored'.",
+          "scenario": "Non-IM-member calls my_status expecting an error; operation is silently ignored",
+          "mitigation": "SDK layer should pre-validate IM membership before submitting my_status and return a clear error. UI should show 'not an IM member' instead of 'success'.",
+          "evidence": "my_status_from_non_member=true (will be silently ignored)",
+          "stakeholders": ["im_member"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-CONTACT-06",
+      "dimension": "semantic",
+      "trigger": "IM-entry description validated with LONG_NAME semantics",
+      "cases": [
+        {
+          "when": { "field": "im_add_description_uses_long_name", "op": "eq", "value": true },
+          "level": "low",
+          "title": "The IM-entry description uses LONG_NAME validation (not DESCRIPTION) — different length cap",
+          "description": "The description parameter for adding an IM entry is validated with common::LONG_NAME rather than common::DESCRIPTION. The two validators have different length limits; callers expecting DESCRIPTION semantics may submit overly long strings and hit an unexpected abort.",
+          "scenario": "Caller submits an IM-entry description sized for DESCRIPTION but hits LONG_NAME limit",
+          "mitigation": "Document that the IM-entry description uses LONG_NAME validation. SDK should expose the exact limit so callers size their strings correctly.",
+          "evidence": "IM entry description validated with LONG_NAME",
+          "stakeholders": ["creator"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-CONTACT-07",
+      "dimension": "cross_object",
+      "trigger": "Contact bound as a Permission's um",
+      "cases": [
+        {
+          "when": { "field": "bound_to_permission_um", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Binding a Contact as a Permission's um creates a bidirectional dependency",
+          "description": "When a Contact is bound as a Permission's um, a bidirectional dependency forms: Permission.um → Contact, and Contact.permission → Permission. Deleting the Contact without first clearing the um reference leaves a dangling pointer in Permission.um.",
+          "scenario": "Contact is deleted while still bound as Permission.um; Permission.um becomes dangling",
+          "mitigation": "Document the deletion order: (1) unbind Permission.um (set it to null) first, (2) then delete the Contact. SDK should refuse to delete a Contact that is still bound as a um.",
+          "evidence": "bound_to_permission_um=true (deletion requires unbinding)",
+          "stakeholders": ["creator", "consumer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-CONTACT-08",
+      "dimension": "knowledge",
+      "trigger": "contact constants not synced to the knowledge constant table",
+      "cases": [
+        {
+          "when": { "field": "constants_synced", "op": "falsy" },
+          "level": "low",
+          "title": "Knowledge layer & constant sync — RESOLVED",
+          "description": "MAX_IM_COUNT is now synced to onchain-constants.ts (${max_im_count}). The MCP Knowledge layer now includes contact-risk.ts. This risk rule is retained for historical audit and to detect future regressions.",
+          "scenario": "Future regression: someone removes MAX_IM_COUNT from onchain-constants.ts",
+          "mitigation": "Run the onchain-constants sync test to detect drift.",
+          "evidence": "constants_synced=false",
+          "stakeholders": ["system"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-CONTACT-03",
+      "dimension": "semantic",
+      "trigger": "unconditional — fires for every evaluation (appended last by the retired check)",
+      "cases": [
+        {
+          "when": { "field": "always_true", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "IM list mutations emit no events — external indexers must poll",
+          "description": "Adding, removing, or clearing IM entries emits no events. External indexers and notification systems cannot rely on event streams to track IM list changes; they must poll the ims field directly, increasing latency and RPC cost.",
+          "scenario": "Indexer expects an event when an IM entry is added but none is emitted; UI fails to refresh",
+          "mitigation": "External indexers should poll the Contact.ims field on a cadence. A future version may add IMEvent; until then, do not build critical UX on IM event streams.",
+          "stakeholders": ["creator", "consumer"]
+        }
+      ]
+    }
+  ]
+}

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

@@ -0,0 +1,158 @@
+{
+  "comment": "Demand rule pack (R-DEM) — declarative form of the retired in-code Demand risk rules. Facts are produced by the kernel extractor (demand-risk.ts, bound to the on-chain demand limits and the SDK feedback batch cap); 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": {
+    "reward_count": "Number of reward addresses in Demand.rewards.",
+    "reward_count_over_limit": "reward_count exceeds MAX_REWARD_COUNT (chain-limit comparison sunk into the extractor).",
+    "guard_count": "Number of ServiceGuard entries in Demand.guards.",
+    "guard_count_over_limit": "guard_count exceeds MAX_GUARD_COUNT_DEMAND (chain-limit comparison sunk into the extractor).",
+    "feedback_count": "Number of feedback entries being submitted in a single SDK batch.",
+    "feedback_count_over_limit": "feedback_count exceeds the SDK MAX_FEEDBACK_COUNT batch cap (chain-limit comparison sunk into the extractor).",
+    "using_present_without_passport": "The caller is trying to call present (not the passport-guarded path).",
+    "guards_non_empty": "Demand.guards is non-empty.",
+    "constants_synced": "Whether the knowledge constants are synced (false keeps the four RESOLVED regression-watch rules audible).",
+    "max_reward_count": "KERNEL CONSTANT — rewards vector cap (MAX_REWARD_COUNT).",
+    "max_guard_count_demand": "KERNEL CONSTANT — guards vector cap (MAX_GUARD_COUNT_DEMAND).",
+    "max_feedback_count": "KERNEL CONSTANT — SDK feedback batch cap, 20 (SDK-only limit, not an on-chain constant)."
+  },
+  "rules": [
+    {
+      "rule_id": "R-DEM-01",
+      "dimension": "structural",
+      "trigger": "rewards vector exceeds MAX_REWARD_COUNT",
+      "cases": [
+        {
+          "when": { "field": "reward_count_over_limit", "op": "eq", "value": true },
+          "level": "high",
+          "title": "rewards count exceeds MAX_REWARD_COUNT (${max_reward_count})",
+          "description": "The 'rewards' vector is bounded by MAX_REWARD_COUNT=${max_reward_count}. Exceeding this limit aborts with E_MAX_REWARD_COUNT_EXCEEDED (1). Each reward is bound through an affiliation link, so adding a reward also re-affirms that link. Use reward removal/clearing to free slots before adding new ones if the limit is reached.",
+          "scenario": "Caller adds a reward when 20 rewards are already affiliated",
+          "mitigation": "Track the current reward count. Before adding a new reward, remove or clear existing rewards to free a slot. Consider consolidating rewards into a single Reward object with multiple tiers if the  Demand needs to offer more than 20 distinct reward paths.",
+          "evidence": "reward_count=${reward_count}, limit=${max_reward_count}",
+          "stakeholders": ["creator"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-DEM-02",
+      "dimension": "structural",
+      "trigger": "guards vector exceeds MAX_GUARD_COUNT_DEMAND",
+      "cases": [
+        {
+          "when": { "field": "guard_count_over_limit", "op": "eq", "value": true },
+          "level": "high",
+          "title": "guards count exceeds MAX_GUARD_COUNT_DEMAND (${max_guard_count_demand})",
+          "description": "The 'guards' vector is bounded by MAX_GUARD_COUNT_DEMAND=${max_guard_count_demand}. Exceeding this limit aborts with E_MAX_GUARD_COUNT_EXCEEDED (2). Each guard carries an optional service_identifier (u8) that routes passport-guarded presentations to a specific Service submission extracted from the Passport. Adding a duplicate guard updates the service_identifier instead of pushing.",
+          "scenario": "Caller calls guard_add when 20 guards are already affiliated and the address is new",
+          "mitigation": "Track the current guard count. Before adding a new guard, remove or clear guards. If updating an existing guard's service_identifier, call guard_add with the same address (it updates in place rather than pushing).",
+          "evidence": "guard_count=${guard_count}, limit=${max_guard_count_demand}",
+          "stakeholders": ["creator", "presenter"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-DEM-03",
+      "dimension": "structural",
+      "trigger": "SDK feedback batch exceeds MAX_FEEDBACK_COUNT",
+      "cases": [
+        {
+          "when": { "field": "feedback_count_over_limit", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "feedback batch exceeds MAX_FEEDBACK_COUNT (${max_feedback_count})",
+          "description": "The feedback call updates ONE presenter per call (the internal implementation iterates no vector). The SDK batches multiple feedback calls and caps the batch at MAX_FEEDBACK_COUNT=${max_feedback_count} (SDK-only limit, NOT in onchain-constants.ts — Move has no aggregate feedback-count check). Exceeding the SDK batch limit causes the SDK to refuse the call before transaction building. Each feedback entry writes a String (bounded by common::DESCRIPTION, 4000 chars) and an optional u8 acceptance_score to a presenter's ServiceInfo record.",
+          "scenario": "Caller attempts to submit 21 feedback entries in a single SDK call",
+          "mitigation": "Split the feedback batch into chunks of ≤ 20 entries. If the Demand has more than 20 presenters to give feedback on, submit multiple transactions. Consider whether bulk feedback is appropriate — individualized feedback per presenter is often more meaningful.",
+          "evidence": "feedback_count=${feedback_count}, limit=${max_feedback_count}",
+          "stakeholders": ["creator"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-DEM-04",
+      "dimension": "semantic",
+      "trigger": "plain present called on a Demand whose guards vector is non-empty",
+      "cases": [
+        {
+          "when": { "all": [
+            { "field": "using_present_without_passport", "op": "eq", "value": true },
+            { "field": "guards_non_empty", "op": "eq", "value": true }
+          ] },
+          "level": "high",
+          "title": "present called without passport when guards vector is non-empty",
+          "description": "The Move present function asserts the guards vector is empty and aborts with E_NEED_PASSPORT (3) if the guards vector is non-empty. When guards exist, every presenter MUST go through the passport-guarded presentation path (or its service-specific variant), which routes through the guarded presentation implementation. That path looks up the specified Guard in the guards vector, runs the passport verification against it to verify the Passport, and (if service_identifier is set) extracts the submission address from the Passport. Calling plain `present` on a guarded Demand always aborts — there is no fallback path.",
+          "scenario": "Demand has 2 guards; a presenter calls present() instead of the passport-guarded presentation",
+          "mitigation": "Before presenting, query the Demand's guards vector. If non-empty, use the passport-guarded presentation and supply a Guard + Passport. The Guard address must already be in the guards vector (otherwise E_GUARD_NOT_FOUND (4) aborts). If service_identifier is set on the matching guard, the submission address is extracted from the Passport — do not pass a separate service parameter.",
+          "evidence": "guards_non_empty=true, using present (no passport)",
+          "stakeholders": ["presenter", "creator"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-DEM-05",
+      "dimension": "lifecycle",
+      "trigger": "regression watch — constants_synced false keeps the RESOLVED um-binding fix audible",
+      "cases": [
+        {
+          "when": { "field": "constants_synced", "op": "falsy" },
+          "level": "info",
+          "title": "um binding update object-linker dependency leak — RESOLVED (P-DEM-P1-1)",
+          "description": "PREVIOUS RISK: the um binding update previously set self.um to the new Contact address BEFORE disaffiliating the old um, causing the old Contact to retain a stale object-linker binding record in the object_linker. The affiliation-change routine was not called for the old um, leading to an object-linker dependency leak.\n\nFIX (P-DEM-P1-1): the um binding update now disaffiliates the old um through a disaffiliation transaction BEFORE setting the new one. The new um is then affiliated through an affiliation link. This matches the pattern used by the permission rebind path (which uses the affiliation-change routine). The um-clearing path also disaffiliates before clearing.\n\nThis rule is retained for historical audit and to detect regressions.",
+          "scenario": "Future regression: someone reorders the um binding update to set new before disaffiliating old",
+          "mitigation": "Keep the disaffiliate-then-set ordering. The Move invariant: any path that mutates self.um MUST run the disaffiliation on the old value before assigning a new one.",
+          "evidence": "constants_synced=false (regression check)",
+          "stakeholders": ["creator", "system"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-DEM-06",
+      "dimension": "semantic",
+      "trigger": "regression watch — constants_synced false keeps the RESOLVED guard-add type-check fix audible",
+      "cases": [
+        {
+          "when": { "field": "constants_synced", "op": "falsy" },
+          "level": "info",
+          "title": "guard-add service_identifier type check skipped on early return — RESOLVED (P-DEM-P1-2)",
+          "description": "PREVIOUS RISK: the guard-add path previously had the service_identifier type check AFTER the early-return path that updates an existing guard's service_identifier. When a guard with the same address already existed, the function returned before validating the new service_identifier against the guard's submission object-type check. This allowed setting an invalid service_identifier that would later fail at passport-guarded presentation time with E_INVALID_SERVICE_OBJECT_TYPE.\n\nFIX (P-DEM-P1-2): The service_identifier type check now runs FIRST, BEFORE the duplicate-detection loop. The service object-type assertion is called for any non-None service_identifier, ensuring both the insert and update paths validate the type.\n\nThis rule is retained for historical audit and to detect regressions.",
+          "scenario": "Future regression: someone moves the type check back to after the duplicate-detection loop",
+          "mitigation": "Keep the type check at the top of the guard-add path. The Move invariant: any service_identifier provided to guard_add MUST be validated via the submission object-type and service object-type checks BEFORE any mutation of the guards vector.",
+          "evidence": "constants_synced=false (regression check)",
+          "stakeholders": ["creator", "presenter"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-DEM-07",
+      "dimension": "knowledge",
+      "trigger": "regression watch — constants_synced false keeps the RESOLVED enrichment contract audible",
+      "cases": [
+        {
+          "when": { "field": "constants_synced", "op": "falsy" },
+          "level": "info",
+          "title": "Demand matching must not read non-existent Move fields — RESOLVED (P-DEM-P1-3)",
+          "description": "PREVIOUS RISK: the retired demand-matching.ts engine (matchDemand/extractDemandInfo) read fields (tags, maxPrice, scenario, minTrustScore, keywords) that do NOT exist on the Move Demand struct. The Move struct only has: description, location, rewards, guards, presenters, um, permission. This caused the matching engine to silently produce undefined values when fed raw on-chain query results.\n\nFIX (P-DEM-P1-3): the capability-vector engine (evaluation/builtins/demand-match.ts) enriches via evaluation/extract.ts (extractDemandCapability/extractServiceCapability). Only `location` maps directly to the Move Demand struct; all other signals (industry/tags/keywords/region/trust/price budget) are enriched from description NLP, the industry generalizer, or caller-injected overrides/data sources.\n\nThis rule is retained for historical audit and to detect regressions.",
+          "scenario": "Future regression: someone removes the enrichment contract docs from evaluation/extract.ts",
+          "mitigation": "Keep the enrichment contract in evaluation/extract.ts (non-chain-derivable fields are enriched there, not read as on-chain fact). The matching engine must never query on-chain data directly — it scores over already-enriched capability vectors.",
+          "evidence": "constants_synced=false (regression check)",
+          "stakeholders": ["system"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-DEM-08",
+      "dimension": "knowledge",
+      "trigger": "regression watch — constants_synced false keeps the RESOLVED rebinding exposure audible",
+      "cases": [
+        {
+          "when": { "field": "constants_synced", "op": "falsy" },
+          "level": "info",
+          "title": "direct Permission rebinding not exposed in SDK — RESOLVED (DE-D-2=A)",
+          "description": "PREVIOUS GAP: The Move permission-rebinding function was not exposed as a standalone function in the SDK's call/demand.ts. Callers could not change the Permission object bound to a Demand after creation.\n\nRESOLUTION (DE-D-2=A): the rebinding is now exposed via the CallPermission.apply mechanism. The SDK wraps it by routing through CallPermission, which performs the owner assert on the old Permission and updates the Demand's bound permission. The object-linker affiliation-change routine is called to migrate the binding from the old Permission to the new one.\n\nPermission indices for Demand: 400=DEMAND_NEW, 401=DEMAND_DESCRIPTION, 402=DEMAND_LOCATION, 404=DEMAND_GUARD, 405=DEMAND_REWARD, 406=DEMAND_FEEDBACK, 407=DEMAND_OWNER_RECEIVE, 408=DEMAND_UM.\n\nThis rule is retained for historical audit and to detect regressions.",
+          "scenario": "Future regression: someone removes the CallPermission.apply path for the permission rebinding",
+          "mitigation": "Keep the permission rebinding exposed via CallPermission.apply. The Move invariant: rebinding requires the owner assert on the old Permission and MUST run the affiliation-change routine to migrate the binding.",
+          "evidence": "constants_synced=false (regression check)",
+          "stakeholders": ["creator", "system"]
+        }
+      ]
+    }
+  ]
+}