@wowok/agent-mcp 3.1.3 → 3.1.5

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

@@ -0,0 +1,158 @@
+{
+  "comment": "Proof rule pack (R-PROOF) — declarative form of the retired in-code Proof risk rules. Facts are produced by the kernel extractor (proof-risk.ts, bound to the on-chain proof/pubkey/signature size limits and the reserved proof_type range); 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-PROOF-07 stays LAST in the array: it is the unconditional immutability reminder the retired check appended after every evaluation.",
+  "facts": {
+    "proof_length": "Length of the 'proof' content string, passed through for evidence text.",
+    "proof_size_exceeded": "True when a non-empty proof content exceeds the chain proof size limit.",
+    "server_pubkey_length": "Length of the server_pubkey string, passed through for evidence text.",
+    "server_pubkey_size_exceeded": "True when a non-empty server_pubkey exceeds the chain pubkey size limit.",
+    "server_signature_length": "Length of the server_signature string, passed through for evidence text.",
+    "server_signature_size_exceeded": "True when a non-empty server_signature exceeds the chain signature size limit.",
+    "proof_type": "Raw proof_type value (number / bigint / numeric string), passed through for evidence text.",
+    "proof_type_reserved": "True when proof_type is provided, is not the WTS type, and falls in the Wowok-reserved 2-100 range.",
+    "about_address": "Raw about_address value — falsy (null/undefined/empty) means the Proof has no on-chain binding.",
+    "description_empty": "True when description is provided but is the empty string.",
+    "constants_synced": "True when the proof 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_proof_size": "KERNEL CONSTANT — maximum proof content size in bytes.",
+    "max_server_pubkey_size": "KERNEL CONSTANT — maximum server_pubkey size in bytes.",
+    "max_server_signature_size": "KERNEL CONSTANT — maximum server_signature size in bytes.",
+    "wowok_wts_proof_type": "KERNEL CONSTANT — the proof_type value reserved for Will-To-Sign (WTS) proofs."
+  },
+  "rules": [
+    {
+      "rule_id": "R-PROOF-01",
+      "dimension": "structural",
+      "trigger": "proof content exceeds the chain proof size limit",
+      "cases": [
+        {
+          "when": { "field": "proof_size_exceeded", "op": "eq", "value": true },
+          "level": "high",
+          "title": "proof content exceeds MAX_PROOF_SIZE (${max_proof_size} bytes)",
+          "description": "The 'proof' string field is bounded by MAX_PROOF_SIZE=${max_proof_size} bytes. Exceeding this limit aborts with E_MAX_PROOF_SIZE (1). The proof content typically holds a merkle tree root or similar compact cryptographic digest — large data should be stored in a Repository and referenced by address, not inlined into the Proof object.",
+          "scenario": "Caller submits a proof string longer than 10240 bytes",
+          "mitigation": "Keep proof content compact (merkle root, hash digest). For larger payloads, store data in a Repository object and set about_address to the Repository address, or use item_count to indicate the off-chain data size.",
+          "evidence": "proof.length=${proof_length}, limit=${max_proof_size}",
+          "stakeholders": ["creator"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-PROOF-02",
+      "dimension": "structural",
+      "trigger": "server_pubkey exceeds the chain pubkey size limit",
+      "cases": [
+        {
+          "when": { "field": "server_pubkey_size_exceeded", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "server_pubkey exceeds MAX_SERVER_PUBKEY_SIZE (${max_server_pubkey_size} bytes)",
+          "description": "The 'server_pubkey' field is bounded by MAX_SERVER_PUBKEY_SIZE=${max_server_pubkey_size} bytes. Exceeding this limit aborts with E_MAX_SERVER_PUBKEY_SIZE (2). Typical public keys (Ed25519=32 bytes, RSA-2048=256 bytes, BLS12-381 G1=48 bytes, G2=96 bytes) fit comfortably within this limit.",
+          "scenario": "Caller submits an oversized server public key (e.g. certificate chain instead of raw key)",
+          "mitigation": "Submit only the raw public key bytes (hex-encoded), not a full certificate or JWK structure.",
+          "evidence": "server_pubkey.length=${server_pubkey_length}, limit=${max_server_pubkey_size}",
+          "stakeholders": ["creator"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-PROOF-03",
+      "dimension": "structural",
+      "trigger": "server_signature exceeds the chain signature size limit",
+      "cases": [
+        {
+          "when": { "field": "server_signature_size_exceeded", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "server_signature exceeds MAX_SERVER_SIGNATURE_SIZE (${max_server_signature_size} bytes)",
+          "description": "The 'server_signature' field is bounded by MAX_SERVER_SIGNATURE_SIZE=${max_server_signature_size} bytes. Exceeding this limit aborts with E_MAX_SERVER_SIGNATURE_SIZE (3). Most signature schemes produce signatures well under this limit (Ed25519=64 bytes, ECDSA=64-72 bytes, BLS12-381=96 bytes, RSA-2048=256 bytes).",
+          "scenario": "Caller submits an oversized signature (e.g. bundled with metadata)",
+          "mitigation": "Submit only the raw signature bytes (hex-encoded), not bundled metadata or certificate chains.",
+          "evidence": "server_signature.length=${server_signature_length}, limit=${max_server_signature_size}",
+          "stakeholders": ["creator"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-PROOF-04",
+      "dimension": "semantic",
+      "trigger": "proof_type falls in the Wowok-reserved 2-100 range without authority",
+      "cases": [
+        {
+          "when": { "field": "proof_type_reserved", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "proof_type in reserved range without authority (1-100 reserved for Wowok)",
+          "description": "proof_type=${wowok_wts_proof_type} is WOWOK_WTS_PROOF_TYPE (Will-To-Sign). Values 2-100 are reserved for future Wowok-defined proof types. User-defined proof types must use values > 100. While the Move contract does not currently enforce this range at the type level (it accepts any u64), using a reserved value without authority creates semantic confusion: consumers may misinterpret the proof's verification rules.",
+          "scenario": "User creates a custom proof with proof_type=5 (a reserved value)",
+          "mitigation": "Use proof_type > 100 for user-defined proof types. Use proof_type=1 only for WTS proofs signed by an off-chain server (with server_pubkey + server_signature). Document the verification rule for custom types.",
+          "evidence": "proof_type=${proof_type} (reserved range 2-100)",
+          "stakeholders": ["creator", "consumer", "verifier"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-PROOF-05",
+      "dimension": "semantic",
+      "trigger": "about_address left null/undefined",
+      "cases": [
+        {
+          "when": { "field": "about_address", "op": "falsy" },
+          "level": "low",
+          "title": "about_address not provided — consumers cannot locate the referenced entity",
+          "description": "about_address is the on-chain address of the entity being proved (e.g. a user, an order, a Repository). When null/undefined, the Proof has no on-chain binding — it is a free-standing cryptographic statement. Consumers (Repository, Service, etc.) that reference this Proof cannot automatically resolve which entity it applies to. This is acceptable for generic proofs but problematic for entity-bound attestations.",
+          "scenario": "Caller creates a Proof without about_address, then a Repository tries to bind it to a data entry",
+          "mitigation": "Set about_address when the Proof attests to a specific on-chain entity. Leave it null only for free-standing cryptographic statements (e.g. a server's timestamp attestation).",
+          "evidence": "about_address=null/undefined",
+          "stakeholders": ["creator", "consumer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-PROOF-06",
+      "dimension": "lifecycle",
+      "trigger": "description provided as the empty string",
+      "cases": [
+        {
+          "when": { "field": "description_empty", "op": "eq", "value": true },
+          "level": "low",
+          "title": "description missing — Proof hard to identify in queries and audit logs",
+          "description": "description is a REQUIRED field (PF-D-2=A). The Move contract stores it as a String field and SDK passes it to the proof-creation call. An empty description (\"\") is technically valid but makes the Proof hard to identify in query results and audit logs. Non-empty descriptions are strongly recommended.",
+          "scenario": "Caller passes description=\"\" to save typing",
+          "mitigation": "Provide a one-line description like \"KYC attestation for user 0xabc\" or \"merkle root for batch #42\".",
+          "evidence": "description=\"\" (empty)",
+          "stakeholders": ["creator", "verifier"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-PROOF-08",
+      "dimension": "knowledge",
+      "trigger": "proof constants not synced to the knowledge constant table",
+      "cases": [
+        {
+          "when": { "field": "constants_synced", "op": "falsy" },
+          "level": "info",
+          "title": "Knowledge layer & constant sync — RESOLVED",
+          "description": "All 4 Proof constants (WOWOK_WTS_PROOF_TYPE, MAX_PROOF_SIZE, MAX_SERVER_PUBKEY_SIZE, MAX_SERVER_SIGNATURE_SIZE) are now synced to onchain-constants.ts (P-PROOF-P2-5). The MCP Knowledge layer now includes proof-risk.ts, proof-confirm.ts, proof-translation.ts (P-PROOF-P2-6). This risk rule is retained for historical audit and to detect future regressions.",
+          "scenario": "Future regression: someone removes a Proof constant from onchain-constants.ts",
+          "mitigation": "Run the onchain-constants sync test to detect drift.",
+          "evidence": "constants_synced=false",
+          "stakeholders": ["system"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-PROOF-07",
+      "dimension": "lifecycle",
+      "trigger": "unconditional — fires for every evaluation (appended last by the retired check)",
+      "cases": [
+        {
+          "when": { "field": "always_true", "op": "eq", "value": true },
+          "level": "high",
+          "title": "Proof is immutable — cannot modify after creation (freeze_object)",
+          "description": "Proof is created via transfer::freeze_object(obj) in Move. Once frozen, the object cannot be modified, transferred, or deleted. All fields (proof, server_pubkey, server_signature, about, proof_type, signer, time, description, item_count) are permanently fixed at the value set during creation. To 'update' a Proof, create a new one and update references.",
+          "scenario": "Caller wants to update server_signature after key rotation — cannot, must create new Proof",
+          "mitigation": "Verify all fields before creating the Proof. For scenarios requiring key rotation, create a new Proof and update the referencing object (Repository data, Service config, etc.) to point to the new Proof address.",
+          "stakeholders": ["creator", "consumer"]
+        }
+      ]
+    }
+  ]
+}

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

@@ -0,0 +1,159 @@
+{
+  "comment": "Registrar+Entity rule pack (R-REG) — declarative form of the retired in-code Registrar/Entity risk rules. Facts are produced by the kernel extractor (registrar-risk.ts, bound to the on-chain registrar limits and the Vote.info bitmask); 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_singleton_migration": "The caller assumes the Entity/Registrar system singletons can be re-deployed or migrated (they cannot).",
+    "address_count": "Number of addresses registered (or about to be registered) in the Entity/Registrar ParentTables.",
+    "address_count_at_limit": "address_count has reached MAX_ADDRESS_COUNT (chain-limit comparison sunk into the extractor).",
+    "uses_reserved_vote_bits": "The caller relies on reserved Vote.info bits 4-7 staying unused.",
+    "expects_fresh_resource_on_register": "The caller calls entity_register expecting a fresh Resource (registration is idempotent).",
+    "expects_affiliation_event": "The caller expects object-linker affiliation/disaffiliation to emit events (none are emitted).",
+    "relies_on_typed_value_convention": "The caller relies on the Record.typed_value first-byte ValueType convention (docs-only enforcement).",
+    "is_resource_transfer": "The caller is performing an entity resource transfer.",
+    "expects_vote_time_only_on_like": "The caller expects Vote.time to update only on like (it updates on every toggle).",
+    "bit_no_info": "KERNEL CONSTANT — Vote.info bitmask value for no-info (BIT_NO_INFO).",
+    "bit_like": "KERNEL CONSTANT — Vote.info bitmask value for like (BIT_LIKE).",
+    "bit_dislike": "KERNEL CONSTANT — Vote.info bitmask value for dislike (BIT_DISLIKE).",
+    "bit_affiliation": "KERNEL CONSTANT — Vote.info bitmask value for affiliation (BIT_AFFILIATION).",
+    "max_address_count": "KERNEL CONSTANT — ParentTable address cap (MAX_ADDRESS_COUNT).",
+    "max_record_length": "KERNEL CONSTANT — per-record byte cap (MAX_RECORD_LENGTH).",
+    "max_record_count_registrar": "KERNEL CONSTANT — per-user record count cap (MAX_RECORD_COUNT_REGISTRAR)."
+  },
+  "rules": [
+    {
+      "rule_id": "R-REG-01",
+      "dimension": "lifecycle",
+      "trigger": "caller assumes the Entity/Registrar singletons can be migrated post-deploy",
+      "cases": [
+        {
+          "when": { "field": "expects_singleton_migration", "op": "eq", "value": true },
+          "level": "high",
+          "title": "Entity and Registrar are system singletons — cannot be migrated post-deploy",
+          "description": "Entity and Registrar are created once at package init by @0x0 and are globally unique. They cannot be re-created, migrated, or re-initialized. If the singleton's storage layout needs to change (e.g. ParentTable schema), the only option is a new package version with a migration path. There is no in-place migration API. All 22 objects depend on these singletons via object-linker bindings, so a migration would cascade to every object.",
+          "scenario": "Operator wants to migrate Entity to a new schema; no migration API exists",
+          "mitigation": "Confirm the schema before deployment. For schema evolution, plan a new package version with an explicit migration script. Never assume the singleton can be 'reset'.",
+          "evidence": "expects_singleton_migration=true (no migration API)",
+          "stakeholders": ["system", "user"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REG-02",
+      "dimension": "structural",
+      "trigger": "registered address count reaches MAX_ADDRESS_COUNT",
+      "cases": [
+        {
+          "when": { "field": "address_count_at_limit", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "MAX_ADDRESS_COUNT=${max_address_count} may be insufficient for large deployments",
+          "description": "The Entity and Registrar ParentTables are bounded by MAX_ADDRESS_COUNT=${max_address_count}. Exceeding the cap aborts address registration. For mass-market applications, ${max_address_count} entries may be too few; the limit is a single Move constant that requires a package upgrade to change.",
+          "scenario": "Popular service reaches 5200 registered users; new registrations abort",
+          "mitigation": "Monitor address_count. Plan a package upgrade that raises MAX_ADDRESS_COUNT before hitting the cap. For shardable workloads, consider multiple Entity tables in a future package version.",
+          "evidence": "address_count=${address_count}, limit=${max_address_count}",
+          "stakeholders": ["system", "user"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REG-03",
+      "dimension": "semantic",
+      "trigger": "caller relies on reserved Vote.info bits 4-7",
+      "cases": [
+        {
+          "when": { "field": "uses_reserved_vote_bits", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Vote.info uses u8 bitmask — bits 4-7 reserved, future expansion must stay compatible",
+          "description": "Vote.info is a u8 bitmask: BIT_NO_INFO=${bit_no_info}, BIT_LIKE=${bit_like}, BIT_DISLIKE=${bit_dislike}, BIT_AFFILIATION=${bit_affiliation}. Bits 4-7 are reserved. A future version that repurposes bits 4-7 would conflict with any off-chain code that reads the raw byte. The reserved bits MUST be treated as zero today; non-zero values in bits 4-7 indicate a forward-incompatible voter.",
+          "scenario": "Future version assigns bit 4 to a new flag; old indexers misread the byte",
+          "mitigation": "Off-chain code must mask to bits 0-3 today and ignore bits 4-7. When a new flag is assigned, ship a coordinated Move + SDK + indexer update.",
+          "evidence": "uses_reserved_vote_bits=true (bits 4-7 are reserved)",
+          "stakeholders": ["voter", "system"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REG-05",
+      "dimension": "cross_object",
+      "trigger": "caller expects object-linker affiliation changes to emit events",
+      "cases": [
+        {
+          "when": { "field": "expects_affiliation_event", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "object-linker affiliation / disaffiliation emit no events — indexers must poll object_linker tables",
+          "description": "The affiliation binding, unbinding, and binding-change operations mutate the binding graph but emit no events. External indexers that track the object-dependency graph cannot rely on an event stream; they must poll the ParentTable, which is expensive as the graph grows.",
+          "scenario": "Indexer expects an AffiliationEvent; none is emitted, dependency graph is stale",
+          "mitigation": "Indexers should poll object_linker tables on a cadence and diff. Future versions may add AffiliationEvent; until then, do not build critical UX on affiliation event streams.",
+          "evidence": "expects_affiliation_event=true (no events)",
+          "stakeholders": ["system"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REG-04",
+      "dimension": "lifecycle",
+      "trigger": "caller expects a fresh Resource from idempotent registration",
+      "cases": [
+        {
+          "when": { "field": "expects_fresh_resource_on_register", "op": "eq", "value": true },
+          "level": "low",
+          "title": "Registration is idempotent — returns existing Resource, not a fresh one",
+          "description": "Registration checks whether the sender already has an Entity record. If so, it returns the existing Resource address without creating a new one. Callers who expect a fresh Resource on each call (e.g. after a forced destroy) will silently receive the old one. Use the forced re-registration path to force-reallocate, and only when the old Resource is truly gone.",
+          "scenario": "User destroys their Resource then re-registers; gets the old (now-invalid) address",
+          "mitigation": "Document the idempotent behavior. After a forced destroy, callers MUST use the forced re-registration path. SDK should detect destroyed Resource and route accordingly.",
+          "evidence": "expects_fresh_resource_on_register=true (idempotent)",
+          "stakeholders": ["user"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REG-06",
+      "dimension": "semantic",
+      "trigger": "caller relies on the Record.typed_value ValueType byte convention",
+      "cases": [
+        {
+          "when": { "field": "relies_on_typed_value_convention", "op": "eq", "value": true },
+          "level": "low",
+          "title": "Record.typed_value first byte is a ValueType — convention enforced only by docs",
+          "description": "Record.typed_value is a vector<u8> whose first byte encodes the ValueType. The Move layer validates that the vector is non-empty and within MAX_RECORD_LENGTH=${max_record_length}, but it does not validate that the first byte is a known ValueType. Off-chain consumers must agree on the ValueType byte layout; a misencoded record will deserialize to garbage without an on-chain abort. Record count is bounded by MAX_RECORD_COUNT_REGISTRAR=${max_record_count_registrar}.",
+          "scenario": "Caller writes a record with first byte 0xFF; no on-chain error, but consumers cannot decode",
+          "mitigation": "SDK must validate the first byte against the ValueType enum before submitting. Document the ValueType byte layout in both Move and SDK. Add a sync test that asserts the ValueType enum matches across layers.",
+          "evidence": "relies_on_typed_value_convention=true (docs-only enforcement)",
+          "stakeholders": ["user", "system"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REG-07",
+      "dimension": "cross_object",
+      "trigger": "an entity resource transfer detaches the Resource from its source address",
+      "cases": [
+        {
+          "when": { "field": "is_resource_transfer", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Resource transfer detaches the Resource from the source address",
+          "description": "The entity resource transfer moves the Resource backing a user's identity mark to a new address. After transfer, the source address has no Resource — any downstream service that keyed identity on the source address loses the binding. There is no automatic forwarding stub left behind.",
+          "scenario": "User transfers Resource to a new wallet; old-wallet-based services break",
+          "mitigation": "Surface a 'transfer will detach the Resource from this address' warning. Consumers should track users by Resource address, not by user address. Provide a migration window where both addresses are valid.",
+          "evidence": "is_resource_transfer=true (source loses Resource)",
+          "stakeholders": ["user", "system"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REG-08",
+      "dimension": "semantic",
+      "trigger": "caller expects Vote.time to advance only on like",
+      "cases": [
+        {
+          "when": { "field": "expects_vote_time_only_on_like", "op": "eq", "value": true },
+          "level": "low",
+          "title": "Vote.time updates on every toggle — including like→no-like",
+          "description": "Vote.time is set to clock.timestamp_ms() on every like/dislike operation, including toggles that remove a like (like→no-like). Consumers who interpret Vote.time as 'last liked at' will be confused when it advances on an un-like. The field semantically means 'last vote op time', not 'last positive vote'.",
+          "scenario": "User un-likes; Vote.time advances; indexer reads it as 'recently liked'",
+          "mitigation": "Document Vote.time as 'last vote operation time'. For 'last liked at' semantics, track the previous Vote.info state and only record time when BIT_LIKE transitions to set.",
+          "evidence": "expects_vote_time_only_on_like=true (updates on toggle)",
+          "stakeholders": ["voter", "system"]
+        }
+      ]
+    }
+  ]
+}

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

@@ -0,0 +1,244 @@
+{
+  "comment": "Repository rule pack (R-REP) — declarative form of the retired in-code Repository risk rules. Facts are produced by the kernel extractor (repository-risk.ts, bound to the live repository limits and the id_from routing semantics); 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": {
+    "policies": "The policy drafts under evaluation (name, id_from routing, write_guard size, submission routing flags).",
+    "existing_policy_count": "Number of policies already stored on the Repository object.",
+    "data_size": "Data payload size in bytes of the current write.",
+    "id_count_once": "Number of data IDs targeted by the current single operation.",
+    "reward_count": "Number of Reward objects referenced by the Repository.",
+    "is_data_remove_with_passport": "Whether the operation is the passport-driven data removal entry point (R-D-2 check).",
+    "constants_synced": "Whether the Repository constants are synced to onchain-constants.ts (the sync reminder fires when falsy).",
+    "has_quote_guard": "Whether quote_guard is set (Some) on any policy.",
+    "quote_guard_is_depended": "Whether the quote_guard satisfies is_depended (immutable + no relies + rep=true).",
+    "quote_guard_verifies_payment": "Whether the quote_guard verifies Payment for subscription.",
+    "has_owner_receive": "Whether the Repository has owner_receive configured for Payment revenue.",
+    "max_policy_count": "KERNEL CONSTANT — live MAX_POLICY_COUNT limit from the published package.",
+    "max_policy_guard_count": "KERNEL CONSTANT — live MAX_POLICY_GUARD_COUNT limit from the published package.",
+    "max_data_size": "KERNEL CONSTANT — live MAX_DATA_SIZE limit in bytes from the published package.",
+    "max_id_count_once": "KERNEL CONSTANT — live MAX_ID_COUNT_ONCE limit from the published package.",
+    "max_reward_count": "KERNEL CONSTANT — live MAX_REWARD_COUNT limit from the published package.",
+    "policies_count": "KERNEL — number of policy drafts being added in this operation.",
+    "total_policy_count": "KERNEL — existing_policy_count + policies_count (present only when both inputs exist).",
+    "policy_count_over_limit": "KERNEL — total_policy_count exceeds the live MAX_POLICY_COUNT.",
+    "policy_none_guard_no_id_count": "KERNEL — policies with id_from=None (caller-provided id) AND an empty write_guard list.",
+    "policy_none_guard_no_id_list": "KERNEL — comma-space joined names of the id_from=None + empty write_guard policies.",
+    "policy_auto_id_submission_count": "KERNEL — policies with id_from=Clock/Signer (auto-generated id) whose guard sets id_from_submission.",
+    "policy_auto_id_submission_list": "KERNEL — comma-space joined 'name(id_from=<raw>)' entries of the auto-id + id_from_submission policies.",
+    "policy_guard_over_limit_count": "KERNEL — policies whose write_guard count exceeds the live MAX_POLICY_GUARD_COUNT.",
+    "policy_guard_over_limit_list": "KERNEL — comma-space joined 'name(count)' entries of the over-limit policies.",
+    "data_size_over_limit": "KERNEL — data_size exceeds the live MAX_DATA_SIZE.",
+    "id_count_over_limit": "KERNEL — id_count_once exceeds the live MAX_ID_COUNT_ONCE.",
+    "reward_count_at_limit": "KERNEL — reward_count has reached the live MAX_REWARD_COUNT (>= limit).",
+    "policy_data_sub_no_id_sub_count": "KERNEL — policies whose guard sets data_from_submission without id_from_submission (Mode 5 mixed write).",
+    "policy_data_sub_no_id_sub_list": "KERNEL — comma-space joined names of the data_from_submission-only policies.",
+    "policy_data_sub_removal_count": "KERNEL — policies whose guard sets data_from_submission while the operation is passport-driven data removal.",
+    "policy_data_sub_removal_list": "KERNEL — comma-space joined names of those policies.",
+    "quote_guard_gap": "KERNEL — what the quote_guard subscription design is missing ('quote_guard does not verify Payment' / 'Repository missing owner_receive for revenue', joined by '; '; empty when fully configured)."
+  },
+  "rules": [
+    {
+      "rule_id": "R-REP-01",
+      "dimension": "structural",
+      "trigger": "existing + new policy count exceeds MAX_POLICY_COUNT",
+      "cases": [
+        {
+          "when": { "field": "policy_count_over_limit", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Policy count exceeds MAX_POLICY_COUNT (${max_policy_count})",
+          "description": "A single Repository may hold up to MAX_POLICY_COUNT=${max_policy_count} policies. Exceeding this limit aborts with E_POLICY_COUNT_EXCEEDED (3) when a policy is added. Each policy defines a named data slot with its own write_guard list and id_from routing — having too many policies makes the Repository hard to audit and increases gas cost for policy lookups (an O(n) scan by policy name).",
+          "scenario": "Caller adds 51 policies to a single Repository",
+          "mitigation": "Consolidate related data under fewer policies. If truly needed, split data across multiple Repository objects and reference them via Service.repository or Progress.context_repositories.",
+          "evidence": "existing=${existing_policy_count}, adding=${policies_count}, total=${total_policy_count}, limit=${max_policy_count}",
+          "stakeholders": ["creator"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REP-02",
+      "dimension": "policy",
+      "trigger": "a policy sets id_from=None with an empty write_guard list",
+      "cases": [
+        {
+          "when": { "field": "policy_none_guard_no_id_count", "op": "gt", "value": 0 },
+          "level": "high",
+          "title": "write_guard empty when id_from=None — unauthorized writes (R-D-1 Move assert)",
+          "description": "When id_from is None, the data ID must be provided by the caller (via the passport-guarded data write or the mixed id+data write). Without a write_guard, ANY address can write data with any ID — this is almost certainly a misconfiguration. The Move contract now enforces this via E_POLICY_WRITE_GUARD_REQUIRED (22) at policy-add time [R-D-1=A].",
+          "scenario": "Caller creates a policy with id_from=None and empty write_guard list",
+          "mitigation": "When id_from=None, provide at least one PolicyGuard entry in write_guard. If you want unrestricted writes, use id_from=Clock or id_from=Signer instead (which auto-generates the ID and requires empty write_guard).",
+          "evidence": "policies with id_from=None + empty write_guard: ${policy_none_guard_no_id_list}",
+          "stakeholders": ["creator", "writer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REP-03",
+      "dimension": "policy",
+      "trigger": "a guard sets id_from_submission while the policy routes id_from=Clock/Signer",
+      "cases": [
+        {
+          "when": { "field": "policy_auto_id_submission_count", "op": "gt", "value": 0 },
+          "level": "high",
+          "title": "id_from_submission set when id_from=Clock/Signer — id routing conflict (R-D-1 Move assert)",
+          "description": "When id_from is Clock or Signer, the data ID is auto-generated (timestamp or signer address). A PolicyGuard with id_from_submission set would try to route the id from a Passport submission, conflicting with the auto-generated id_from path. The Move contract enforces that id_from_submission MUST be None for every PolicyGuard when id_from is Clock/Signer (data_from_submission is still allowed — it is used by the guarded data-extraction entry point to extract data from the submission). Violations abort with E_POLICY_ID_FROM_SUBMISSION_FORBIDDEN (23) at policy-add time [R-D-1=A, refined].",
+          "scenario": "Caller creates a policy with id_from=Clock and a write_guard entry whose id_from_submission is set",
+          "mitigation": "When id_from=Clock or Signer, ensure every PolicyGuard has id_from_submission=null. data_from_submission may still be set if you want the guard to supply the data payload (routed via the guarded data-extraction entry point). If you need submission-derived ids, switch to id_from=None and set id_from_submission on the guard.",
+          "evidence": "policies with id_from=Clock/Signer + id_from_submission set: ${policy_auto_id_submission_list}",
+          "stakeholders": ["creator", "writer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REP-04",
+      "dimension": "structural",
+      "trigger": "a policy's write_guard count exceeds MAX_POLICY_GUARD_COUNT",
+      "cases": [
+        {
+          "when": { "field": "policy_guard_over_limit_count", "op": "gt", "value": 0 },
+          "level": "medium",
+          "title": "Policy write_guard count exceeds MAX_POLICY_GUARD_COUNT (${max_policy_guard_count})",
+          "description": "Each policy may define up to MAX_POLICY_GUARD_COUNT=${max_policy_guard_count} guard entries in its write_guard list. Exceeding this limit aborts with E_POLICY_GUARD_COUNT_EXCEEDED (2). Each entry maps to a Guard object that must be verified via Passport submission, so more guards = more complex write authorization semantics.",
+          "scenario": "Caller creates a policy with 11 guard entries in write_guard",
+          "mitigation": "Consolidate guard logic. If multiple guards must verify the same data, consider composing them into a single Guard with relies/rep fields, or split the data across multiple policies with fewer guards each.",
+          "evidence": "policies exceeding guard count: ${policy_guard_over_limit_list}",
+          "stakeholders": ["creator"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REP-05",
+      "dimension": "structural",
+      "trigger": "a data payload exceeds MAX_DATA_SIZE",
+      "cases": [
+        {
+          "when": { "field": "data_size_over_limit", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Data value exceeds MAX_DATA_SIZE (${max_data_size} bytes)",
+          "description": "A single Repository data value must be ≤ MAX_DATA_SIZE=${max_data_size} bytes. Exceeding this limit aborts with E_DATA_EXCEEDED (4). The value is stored as a BCS-serialized vector<u8> with a type-tag prefix byte. Large data should be stored off-chain (e.g. IPFS, Walrus) and referenced by hash/address, NOT inlined into the Repository data value.",
+          "scenario": "Caller writes a 50KB JSON blob as a Repository data value",
+          "mitigation": "Store large payloads off-chain and write only the content hash (32-64 bytes) to the Repository. Use about_address on a Proof object to bind the off-chain data to an on-chain attestation.",
+          "evidence": "data_size=${data_size}, limit=${max_data_size}",
+          "stakeholders": ["writer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REP-06",
+      "dimension": "routing",
+      "trigger": "a guard sets data_from_submission without id_from_submission (Mode 5 mixed write)",
+      "cases": [
+        {
+          "when": { "field": "policy_data_sub_no_id_sub_count", "op": "gt", "value": 0 },
+          "level": "low",
+          "title": "Policy has data_from_submission but no id_from_submission — verify Mode 5 routing intent",
+          "description": "When a PolicyGuard has data_from_submission set (data comes from Passport submission) but no id_from_submission (id comes from caller), the SDK routes to the mixed id+data passport write (Mode 5). This is a valid but advanced pattern — ensure the caller provides matching id vectors. The SDK hasSubmissionSettings helper now correctly detects this case [P1-1 fix, R-D-3=A].",
+          "scenario": "Policy has a guard with data_from_submission=2, id_from_submission=undefined",
+          "mitigation": "Document the expected caller input shape. Ensure the caller provides both the id vector (positional) and the Passport submission (for data). Verify routing via the SDK hasSubmissionSettings helper.",
+          "evidence": "policies with data_from_submission but no id_from_submission: ${policy_data_sub_no_id_sub_list}",
+          "stakeholders": ["creator", "writer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REP-07",
+      "dimension": "submission",
+      "trigger": "passport-driven data removal targets a policy whose guard sets data_from_submission",
+      "cases": [
+        {
+          "when": { "field": "policy_data_sub_removal_count", "op": "gt", "value": 0 },
+          "level": "high",
+          "title": "data_from_submission set on a policy used for passport-driven data removal — Move will abort (R-D-2)",
+          "description": "Passport-driven data removal only removes data identified by the caller-provided id vector; it cannot consume Passport submissions for either id or data. The Move contract now enforces that BOTH id_from_submission AND data_from_submission MUST be None for this entry point [R-D-2=A], aborting with E_GUARD_SPECIFIED_ID_FROM_SUBMISSION (11). Previously, only id_from_submission was checked, allowing data_from_submission to be silently ignored — masking a routing bug.",
+          "scenario": "Caller uses passport-driven data removal on a policy whose guard has data_from_submission=2",
+          "mitigation": "For data removal via Passport, use the mixed id+data removal entry point instead (which requires id_from_submission and derives the id from the submission). Do not set data_from_submission on policies intended for passport-driven data removal.",
+          "evidence": "policies with data_from_submission used in passport-driven data removal: ${policy_data_sub_removal_list}",
+          "stakeholders": ["writer", "verifier"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REP-08",
+      "dimension": "structural",
+      "trigger": "a single op's ID count exceeds MAX_ID_COUNT_ONCE",
+      "cases": [
+        {
+          "when": { "field": "id_count_over_limit", "op": "eq", "value": true },
+          "level": "low",
+          "title": "ID count per single op exceeds MAX_ID_COUNT_ONCE (${max_id_count_once})",
+          "description": "A single Repository call (data_add, data_remove, id_data_*) may operate on at most MAX_ID_COUNT_ONCE=${max_id_count_once} IDs. Exceeding this limit aborts with E_ID_COUNT_EXCEEDED (5). Batch large operations across multiple transactions.",
+          "scenario": "Caller passes 150 IDs in a single data_remove call",
+          "mitigation": "Split into batches of ≤ ${max_id_count_once} IDs per transaction.",
+          "evidence": "id_count=${id_count_once}, limit=${max_id_count_once}",
+          "stakeholders": ["writer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REP-09",
+      "dimension": "structural",
+      "trigger": "reward count reaches MAX_REWARD_COUNT",
+      "cases": [
+        {
+          "when": { "field": "reward_count_at_limit", "op": "eq", "value": true },
+          "level": "info",
+          "title": "Reward count approaches MAX_REWARD_COUNT (${max_reward_count})",
+          "description": "A Repository may reference up to MAX_REWARD_COUNT=${max_reward_count} Reward objects. Exceeding this limit aborts with E_MAX_REWARD_COUNT_EXCEEDED (19). Rewards incentivize data contribution; having many rewards is fine but increases accounting complexity.",
+          "scenario": "Caller adds 20 rewards to a Repository (at the limit)",
+          "mitigation": "Monitor reward count. If more incentives are needed, consolidate rewards or use a separate Repository.",
+          "evidence": "reward_count=${reward_count}, limit=${max_reward_count}",
+          "stakeholders": ["creator"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REP-10",
+      "dimension": "knowledge",
+      "trigger": "constants drift from onchain-constants.ts / knowledge-layer gaps (sync reminder)",
+      "cases": [
+        {
+          "when": { "field": "constants_synced", "op": "falsy" },
+          "level": "info",
+          "title": "Knowledge layer & constant sync — RESOLVED",
+          "description": "All 6 Repository constants (MAX_POLICY_COUNT, MAX_POLICY_DESCRIPTION_LEN, MAX_POLICY_GUARD_COUNT, MAX_DATA_SIZE, MAX_ID_COUNT_ONCE, MAX_REWARD_COUNT) are now synced to onchain-constants.ts. The MCP Knowledge layer now includes repository-risk.ts, repository-confirm.ts, repository-translation.ts (R-D-4=A). The SDK hasSubmissionSettings helper now correctly checks both id_from_submission AND data_from_submission (P1-1). parseIdFrom is used in data/data_remove (P1-2). This risk rule is retained for historical audit and to detect future regressions.",
+          "scenario": "Future regression: someone removes a Repository constant from onchain-constants.ts",
+          "mitigation": "Run the onchain-constants sync test to detect drift.",
+          "evidence": "constants_synced=false",
+          "stakeholders": ["system"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REP-11",
+      "dimension": "policy",
+      "trigger": "quote_guard set but not dependency-safe",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "has_quote_guard", "op": "truthy" }, { "field": "quote_guard_is_depended", "op": "falsy" } ] },
+          "level": "high",
+          "title": "quote_guard must be dependency-safe (immutable + rep=true + no relies) — Move assert",
+          "description": "Repository policy's quote_guard must satisfy the dependency-safety requirement: immutable=true, relies empty, rep=true. This ensures the quote_guard is a stable, repository-querying guard that can be depended upon. Move aborts with E_NEED_DEPENDENT_GUARD if the guard is not dependency-safe. VERIFIED: passport.rs#L545-612 (check_repository_quote_guard enforces this at query time).",
+          "scenario": "Creator sets quote_guard to a Guard that is not dependency-safe (e.g., has relies or is mutable)",
+          "mitigation": "Ensure the quote_guard Guard object has: immutable=true, relies=empty, rep=true. Use pattern.repository_quote_guard_subscription as the design template.",
+          "evidence": "quote_guard set but not dependency-safe (immutable + rep=true + no relies)",
+          "stakeholders": ["creator", "reader"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REP-12",
+      "dimension": "knowledge",
+      "trigger": "quote_guard subscription without Payment verification or owner_receive revenue",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "has_quote_guard", "op": "truthy" }, { "field": "quote_guard_gap", "op": "truthy" } ] },
+          "level": "medium",
+          "title": "quote_guard data subscription design — verify Payment verification + owner_receive revenue",
+          "description": "When using quote_guard for data subscription (Repository+quote_guard+Payment pattern), ensure: (1) quote_guard verifies Payment fields (for_object matches Repository, amount meets price), (2) Repository has owner_receive<T> configured to accept Payment as subscription revenue. VERIFIED: passport.rs#L545-612. DESIGN: quote_guard is a RIGID verification requirement — any guard querying this Repository's data MUST satisfy the quote_guard (see R-X1-10 in guard-risk.ts).",
+          "scenario": "Creator sets quote_guard but does not configure Payment verification or owner_receive",
+          "mitigation": "1) Ensure quote_guard verifies Payment (for_object, amount); 2) Configure Repository owner_receive<T> to accept subscription Payment revenue; 3) Use pattern.repository_quote_guard_subscription (guard-design-patterns.ts) and tpl_repository_quote_guard_subscription (guard-templates.ts) as design templates.",
+          "evidence": "${quote_guard_gap}",
+          "stakeholders": ["creator", "reader", "verifier"]
+        }
+      ]
+    }
+  ]
+}