@wowok/agent-mcp 3.1.3 → 3.1.4

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

@@ -0,0 +1,981 @@
+{
+  "comment": "Guard rule pack (R-C/R-X) — declarative form of the retired in-code Guard risk rules (the guard condition-tree lint pack: 32 rules over the serialized root, table classification and the scene ledger). Facts are produced by the kernel extractor (guard-risk.ts, bound to the GUARDQUERY invariant catalog, the witness chain table and the per-scene reentrancy specs); 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": {
+    "has_signer_check": "KERNEL — the serialized root contains a context(Signer) check.",
+    "has_clock_check": "KERNEL — the serialized root contains a context(Clock) node.",
+    "has_guard_self_ref": "KERNEL — the serialized root contains a context(Guard) self-reference.",
+    "has_witness": "KERNEL — the serialized root contains a convert_witness field.",
+    "queries_repository": "KERNEL — the serialized root mentions repository (Repository data source).",
+    "queries_progress": "KERNEL — the serialized root mentions progress (Progress data source).",
+    "root_has_query": "KERNEL — the serialized root contains a \"query\" node marker.",
+    "root_has_clock_token": "KERNEL — the lowercased serialized root contains the clock token.",
+    "root_has_calc_number_add": "KERNEL — the serialized root uses calc_number_add.",
+    "root_has_logic_string_contains": "KERNEL — the serialized root uses logic_string_contains.",
+    "root_has_logic_string_nocase": "KERNEL — the serialized root uses the logic_string_nocase variant.",
+    "root_has_logic_as_u256_greater_or_equal": "KERNEL — the serialized root uses logic_as_u256_greater_or_equal.",
+    "root_has_logic_as_u256_greater": "KERNEL — the serialized root uses logic_as_u256_greater (substring semantics: also matches the greater_or_equal form, as the retired code did).",
+    "root_has_logic_equal": "KERNEL — the serialized root contains a logic_equal node.",
+    "root_has_logic_not_equal": "KERNEL — the serialized root contains a logic_not_equal node.",
+    "root_is_identifier": "KERNEL — the root node itself is an identifier node.",
+    "root_identifier_is_submission": "KERNEL — when the root is an identifier, the referenced table entry has b_submission=true (false when the entry is missing or constant).",
+    "root_query_ids_csv": "KERNEL — all GUARDQUERY ids referenced in the root (numeric ids and resolved names), comma-space joined.",
+    "root_has_progress_current_query": "KERNEL — the root queries progress.current (query id 1253).",
+    "logic_and_count": "KERNEL — number of logic_and markers in the serialized root.",
+    "const_addr_list": "KERNEL — constant Address table entries (b_submission=false, value set) rendered as '#id=value', comma joined.",
+    "const_addr_count": "KERNEL — number of constant Address table entries (b_submission=false, value set).",
+    "sys_addr_list": "KERNEL — system-address table entries (0xaab/0xaaa) rendered as '#id=value(name)', comma joined.",
+    "sys_addr_wrong": "KERNEL — a system-address entry's name annotation contradicts the address (0xaab not named *registrar* / 0xaaa not named *linker*).",
+    "witness_multihop_codes": "KERNEL — multi-hop witness codes (106/107/108) present in the root.",
+    "witness_multihop_csv": "KERNEL — witness_multihop_codes comma-space joined.",
+    "witness_multihop_names_block": "KERNEL — one '  - <code>: <chain name>' line per multi-hop witness code, newline joined.",
+    "rc2_02_issue_count": "KERNEL — witness-source table annotation issues found (hard mismatches + missing annotations).",
+    "rc2_02_has_hard_mismatch": "KERNEL — at least one explicit object_type contradiction with the witness derivation chain.",
+    "rc2_02_evidence_lines": "KERNEL — the issue list rendered as '  - <issue>' lines, newline joined.",
+    "rc2_02_evidence_csv": "KERNEL — the issue list joined with '; '.",
+    "rc2_04_queries_repo": "KERNEL — the root queries repository data (translation-relevant).",
+    "rc2_04_queries_progress_history": "KERNEL — the root queries progress history (translation-relevant).",
+    "rc2_04_has_conversion": "KERNEL — the root already uses a type-conversion node (convert_number_address / convert_address_number / convert_u256 / convert_string).",
+    "rc2_04_conversion_note": "KERNEL — final description tail for the conversion-present vs conversion-missing branches.",
+    "rc2_04_conversion_evidence": "KERNEL — final evidence for the conversion-present vs conversion-missing branches.",
+    "has_submission": "KERNEL — the table has at least one b_submission=true entry.",
+    "scene_present": "KERNEL — a binding scene was supplied.",
+    "scene_id": "KERNEL — the binding scene id (e.g. service_order_allocators_guard).",
+    "scene_host_object": "KERNEL — the binding scene host object type (Service/Machine/...).",
+    "scene_binding_field": "KERNEL — the binding scene binding field (buy_guard/order_allocators/...).",
+    "scene_mutable_after_publish": "KERNEL — whether the scene binding can be modified after the host object is published.",
+    "rc3_01_sharing_exempt": "KERNEL — allocators scene with Entity/GuardIdentifier-only sharing (Signer binding advice does not apply; R-C3-06 owns the semantics).",
+    "rc3_02_numeric_count": "KERNEL — submitted numeric table entries (U8..U256) in the voting_guard scene.",
+    "rc3_02_numeric_list": "KERNEL — submitted numeric entries rendered as '#id(TYPE)', comma joined.",
+    "rc3_03_submitted_addr_count": "KERNEL — submitted Address table entries (b_submission=true, value_type=Address).",
+    "rc3_03_no_type_count": "KERNEL — submitted Address entries missing the object_type annotation.",
+    "rc3_03_evidence": "KERNEL — final evidence listing the missing-object_type or annotated entries.",
+    "rc3_05_applies": "KERNEL — a project-relevant object (Order/Progress/Arb) is submitted in an affected scene without a project-binding query (1563/1560/1250/1402/1401) in the root.",
+    "rc3_05_critical": "KERNEL — the scene belongs to the critical set (machine_forward_guard / service_order_allocators_guard).",
+    "rc3_05_unbound_csv": "KERNEL — unbound project-relevant submission entries rendered '#id(Order|Progress|Arb|inferred …)', comma joined.",
+    "rc3_05_scene_label": "KERNEL — scene label for the evidence ('unknown scene (conservative flag)' when absent).",
+    "rc3_06_applies": "KERNEL — allocators scene, Guard without Signer binding, and sharing is not provably Entity/GuardIdentifier-only.",
+    "rc3_06_signer_sharing": "KERNEL — sharing.who=Signer confirmed via the sharing_recipients hint.",
+    "rc3_06_recipients_label": "KERNEL — rendered sharing recipients hint ('[Signer]' or '(not provided — conservative flag)').",
+    "rc3_06_title_suffix": "KERNEL — final title suffix for the confirmed vs conservative branches.",
+    "rc3_06_level_rationale": "KERNEL — final level rationale for the evidence line.",
+    "rc4_01_comparison_detail": "KERNEL — detected comparison operators rendered 'logic_equal(==) logic_not_equal(!=)' (blank when absent).",
+    "rc4_01_comparison_ops": "KERNEL — detected comparison operators rendered '== !=' (blank when absent).",
+    "rc4_02_has_greater_or_equal": "KERNEL — the root uses logic_as_u256_greater_or_equal (Clock boundary form).",
+    "rc4_02_has_greater": "KERNEL — the root uses logic_as_u256_greater (substring semantics).",
+    "rc4_02_comparison_ops": "KERNEL — detected comparison operators rendered '>= >' (blank when absent).",
+    "rc4_04_detected": "KERNEL — Level 1 strict single-identity Signer binding detected (logic_equal[context(Signer), identifier[N]] on a fixed Address constant, not wrapped in logic_or).",
+    "rc4_04_entry_identifier": "KERNEL — table identifier of the detected Level 1 strict-binding entry.",
+    "rc4_04_entry_value": "KERNEL — fixed Address value of the detected entry.",
+    "rc4_04_entry_detail": "KERNEL — entry constraint detail rendered 'b_submission=false, value=\"…\"(, name=\"…\")?'.",
+    "rx1_01_trigger": "KERNEL — greater_or_equal + clock + calc_number_add + query present and at least one root query lacks a non-zero invariant.",
+    "rx1_01_evidence": "KERNEL — final evidence listing queries without a non-zero invariant (or the static fallback).",
+    "rx1_02_trigger": "KERNEL — greater + query present and at least one root query lacks a non-zero invariant.",
+    "rx1_02_evidence": "KERNEL — final evidence listing queries without a non-zero invariant (or the static fallback).",
+    "rely_guards_count": "KERNEL — number of external Guards in the rely configuration.",
+    "rely_is_or": "KERNEL — the rely combination is OR (vs AND).",
+    "rely_logic": "KERNEL — final 'OR'/'AND' label of the rely combination.",
+    "rx1_11_self_rep_false": "KERNEL — this Guard queries repository.data with a submitted Repository address (own rep=false).",
+    "rx1_11_warning_tail": "KERNEL — final description tail appended when own rep=false (empty otherwise).",
+    "rx1_11_evidence": "KERNEL — final evidence for the own rep=false vs to-be-confirmed branches.",
+    "rx1_12_vague_count": "KERNEL — submitted entries with vague name descriptions (< 10 chars, bare identifiers, or empty).",
+    "rx1_12_vague_csv": "KERNEL — vague entries rendered 'identifier=N, name=\"…\"', '; ' joined.",
+    "rx1_13_detected": "KERNEL — a table Address constant's object_type equals the scene host object (circular reference pattern).",
+    "rx1_13_identifier": "KERNEL — identifier of the circular-reference table entry.",
+    "reentry_applicable": "KERNEL — the scene has a reentrancy spec (ALLOWED scenes stay silent).",
+    "reentry_state": "KERNEL — anti-reentrancy protection state: 'protected' / 'pseudo' / 'absent'.",
+    "reentry_scene_id": "KERNEL — reentrancy scene id from the spec table.",
+    "reentry_found_primitive": "KERNEL — GUARDQUERY name of the anti-reentrancy primitive found in the root.",
+    "reentry_evidence": "KERNEL — final detection evidence of the reentrancy scan.",
+    "reentry_rationale": "KERNEL — per-scene reentrancy rationale (spec table, Move-verified).",
+    "reentry_mitigation": "KERNEL — per-scene reentrancy mitigation (spec table, Move-verified)."
+  },
+  "rules": [
+    {
+      "rule_id": "R-C1-01",
+      "dimension": "data_source_trust",
+      "trigger": "Guard table contains Address constants with b_submission=false; values may change after Guard rebuild",
+      "cases": [
+        {
+          "when": { "field": "const_addr_list", "op": "present" },
+          "level": "low",
+          "title": "Constant object addresses may be inconsistent after Guard rebuild",
+          "description": "Guard table contains ${const_addr_count} Address constants (b_submission=false).Guard is immutable, but if a future Guard rebuild is needed (e.g. to fix logic), the new Guard's table constant addresses may differ from the old version.Objects referencing the old Guard (Machine/Service, etc.) will not auto-update, leading to constant address inconsistency.",
+          "scenario": "Guard iteration: after rebuild, constant addresses change but references still point to the old Guard",
+          "mitigation": "1) After Guard rebuild, update all references (Machine forward guard, Service buy_guard, etc.);2) Use guard2file to export a backup and record constant-address-to-semantics mappings;3) Document constant-address changes in the migration notes",
+          "evidence": "Constant Address entries: ${const_addr_list}",
+          "stakeholders": ["provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-C1-02",
+      "dimension": "data_source_trust",
+      "trigger": "Guard table contains EntityRegistrar(0xaab) or EntityLinker(0xaaa) system address constants",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "sys_addr_list", "op": "present" }, { "field": "sys_addr_wrong", "op": "eq", "value": true }] },
+          "level": "medium",
+          "title": "EntityRegistrar/EntityLinker system address name annotation suspected to be wrong",
+          "description": "EntityRegistrar (0xaab) and EntityLinker (0xaaa) are fixed WoWok protocol system addresses.Detected name annotation does not match the address (e.g. 0xaab not annotated as registrar), which may cause semantic misunderstanding.",
+          "scenario": "System address misuse: incorrect 0xaab/0xaaa name annotation causes query target confusion",
+          "mitigation": "1) Confirm 0xaab corresponds to EntityRegistrar (entity registrar);2) Confirm 0xaaa corresponds to EntityLinker (entity linker);3) The table entry name should clearly indicate the system address purpose",
+          "evidence": "System address entries: ${sys_addr_list}",
+          "stakeholders": ["provider"]
+        },
+        {
+          "when": { "all": [{ "field": "sys_addr_list", "op": "present" }, { "field": "sys_addr_wrong", "op": "eq", "value": false }] },
+          "level": "low",
+          "title": "Guard uses EntityRegistrar/EntityLinker system address constants",
+          "description": "EntityRegistrar (0xaab) and EntityLinker (0xaaa) are fixed WoWok protocol system addresses.Address is correct, but ensure the name annotation is clear to avoid later maintenance confusion.",
+          "scenario": "System address misuse: incorrect 0xaab/0xaaa name annotation causes query target confusion",
+          "mitigation": "1) Confirm 0xaab corresponds to EntityRegistrar (entity registrar);2) Confirm 0xaaa corresponds to EntityLinker (entity linker);3) The table entry name should clearly indicate the system address purpose",
+          "evidence": "System address entries: ${sys_addr_list}",
+          "stakeholders": ["provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-C1-03",
+      "dimension": "data_source_trust",
+      "trigger": "Guard queries Repository data without verifying writer permissions",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "queries_repository", "op": "eq", "value": true }, { "field": "has_signer_check", "op": "eq", "value": false }] },
+          "level": "high",
+          "title": "Repository data source does not verify writer permissions",
+          "description": "Guard queries Repository data but does not verify who has permission to write to that Repository.A malicious writer can manipulate Repository data to deceive the Guard. As a Type1 constant object, the Repository's address is immutable, but its internal data can be modified by authorized writers.",
+          "scenario": "Data source manipulation: attacker writes false data so Guard passes",
+          "mitigation": "1) Restrict writer permissions in the Repository write_guard;2) Add context(Signer) in the current Guard to verify writer identity;3) Use multi-point data source cross-validation",
+          "stakeholders": ["customer", "provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-C2-01",
+      "dimension": "data_source_trust",
+      "trigger": "Guard uses multi-hop witness (106/107/108: Arb→Progress/Machine/Service) to derive target object",
+      "cases": [
+        {
+          "when": { "field": "witness_multihop_codes", "op": "truthy" },
+          "level": "medium",
+          "title": "Multi-hop witness chain derivation may break",
+          "description": "Guard uses multi-hop witness [${witness_multihop_csv}] to derive target object.Multi-hop witness (e.g. Arb→Progress requires reading arb.order then order.progress) requires intermediate objects to exist and fields to be set.If an intermediate object does not exist (e.g. Arb's order field is empty) or the relationship chain breaks, witness derivation fails.In the WoWok protocol this usually returns empty or 0, potentially causing unexpected Guard behavior.\n${witness_multihop_names_block}",
+          "scenario": "Witness break: intermediate object missing causes derivation failure and unexpected Guard behavior",
+          "mitigation": "1) Confirm the Arb object's order field is properly set (Arb is bound to Order at creation);2) Add null checks for derived results in Guard logic;3) Prefer single-hop witness (100-105) to reduce derivation chain length;4) Test the edge case where Arb is not associated with an Order",
+          "evidence": "Multi-hop witness codes: ${witness_multihop_csv}",
+          "stakeholders": ["customer", "provider", "arbitrator"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-C2-02",
+      "dimension": "data_source_trust",
+      "trigger": "Guard uses witness but source object's object_type may not match the witness source type, or multi-hop chain has missing intermediate objects",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "rc2_02_issue_count", "op": "gt", "value": 0 }, { "field": "rc2_02_has_hard_mismatch", "op": "eq", "value": true }] },
+          "level": "medium",
+          "title": "witness source object_type explicitly contradicts the witness derivation chain",
+          "description": "Guard uses witness derivation, but the source object's object_type in table is either inconsistent with the witness expected source type, or the annotation is missing (preventing validation), or the multi-hop chain lacks an intermediate object.\n${rc2_02_evidence_lines}\nNote: object_type is an auxiliary annotation field on table entries; it is not strictly validated at on-chain creation. However, wrong or missing annotations cause semantic misunderstanding and maintenance difficulty, and may indicate a deeper structural mismatch.",
+          "scenario": "Type annotation mismatch: witness source type annotation is wrong, causing semantic confusion",
+          "mitigation": "1) Set or fix the table entry's object_type field to match the witness source type;\n2) witness 100-102 source type is Order; 103 is Progress; 104-108 is Arb;\n3) For multi-hop witnesses (106-108), ensure the intermediate Order object is also in the table;\n4) Use wowok_buildin_info(info='guard instructions') to query the full witness definition",
+          "evidence": "${rc2_02_evidence_csv}",
+          "stakeholders": ["provider"]
+        },
+        {
+          "when": { "all": [{ "field": "rc2_02_issue_count", "op": "gt", "value": 0 }, { "field": "rc2_02_has_hard_mismatch", "op": "eq", "value": false }] },
+          "level": "low",
+          "title": "witness source object_type annotation missing or multi-hop chain incomplete",
+          "description": "Guard uses witness derivation, but the source object's object_type in table is either inconsistent with the witness expected source type, or the annotation is missing (preventing validation), or the multi-hop chain lacks an intermediate object.\n${rc2_02_evidence_lines}\nNote: object_type is an auxiliary annotation field on table entries; it is not strictly validated at on-chain creation. However, wrong or missing annotations cause semantic misunderstanding and maintenance difficulty, and may indicate a deeper structural mismatch.",
+          "scenario": "Type annotation missing: witness source type cannot be validated, raising maintenance risk",
+          "mitigation": "1) Set or fix the table entry's object_type field to match the witness source type;\n2) witness 100-102 source type is Order; 103 is Progress; 104-108 is Arb;\n3) For multi-hop witnesses (106-108), ensure the intermediate Order object is also in the table;\n4) Use wowok_buildin_info(info='guard instructions') to query the full witness definition",
+          "evidence": "${rc2_02_evidence_csv}",
+          "stakeholders": ["provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-C2-03",
+      "dimension": "data_source_trust",
+      "trigger": "Guard queries Progress status without verifying Machine publish state",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "queries_progress", "op": "eq", "value": true }, { "field": "has_witness", "op": "eq", "value": true }, { "field": "scene_host_object", "op": "eq", "value": "Machine" }] },
+          "level": "medium",
+          "title": "Progress data depends on Machine immutability",
+          "description": "Guard queries Progress status via witness, and the Guard is bound to a Machine.If the Machine is not published (bPublished=false), the Provider can modify the Machine node structure, causing node names validated by the Guard to become invalid or be renamed. Progress's current node name, node time, etc. all depend on the Machine's node definitions.",
+          "scenario": "Provider modifies Machine node names to invalidate Guard verification",
+          "mitigation": "1) Ensure the Machine is published (bPublished=true) before binding the Guard;2) Query the Machine.bPublished field in the Guard to verify;3) Use node IDs instead of node names for comparison",
+          "stakeholders": ["customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-C2-04",
+      "dimension": "data_source_trust",
+      "trigger": "Guard uses witness query and the query parameter requires type conversion (e.g. Address → U64 timestamp key)",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "has_witness", "op": "eq", "value": true }, { "any": [{ "field": "rc2_04_queries_repo", "op": "eq", "value": true }, { "field": "rc2_04_queries_progress_history", "op": "eq", "value": true }] }] },
+          "level": "medium",
+          "title": "witness query parameter requires type translation (missing will cause type mismatch or wrong comparison)",
+          "description": "Guard queries object fields via witness, but the query parameter type may not match the type declared in table.\nTypical scenarios:\n  - Repository.data query: the key may be of Address type (vector<u8> address representation in Move), but the actual semantics is a U64 timestamp, requiring convert_number_address translation\n  - Progress.history query: Forward ID may need to be converted from String to Address\n  - Order field query: some ID fields may be stored as Address but need U256 for comparison${rc2_04_conversion_note}",
+          "scenario": "Query parameter type does not match the parameters type defined by GUARDQUERY, causing creation failure or runtime comparison error",
+          "mitigation": "1) Query GUARDQUERY to confirm the parameters type and return type of each query instruction;\n2) If table declares Address but the query needs U64, use convert_number_address to translate;\n3) Use wowok_buildin_info info='guard instructions' to verify parameter types;\n4) Verify type compatibility via schema_query before creation",
+          "evidence": "${rc2_04_conversion_evidence}",
+          "stakeholders": ["provider", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-C3-01",
+      "dimension": "submission_forgery",
+      "trigger": "Guard depends on submitted data but does not verify signer identity (no Signer check=high; with Signer check=info downgrade)",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "has_submission", "op": "eq", "value": true }, { "field": "scene_binding_field", "op": "neq", "value": "voting_guard" }, { "field": "rc3_01_sharing_exempt", "op": "eq", "value": false }, { "field": "scene_id", "op": "eq", "value": "machine_forward_guard" }, { "field": "has_signer_check", "op": "eq", "value": false }] },
+          "level": "medium",
+          "title": "Submitted data not bound to signer identity (Forward scenario implicitly verified by permissionIndex)",
+          "description": "Guard accepts runtime-submitted data (b_submission=true), and root does not explicitly verify Signer.This Guard is used for Machine Forward; Forward's permissionIndex/namedOperator already implicitly verifies operator identity, so the Signer binding risk is reduced. But permissionIndex only verifies 'operator has permission', not 'submitted data belongs to operator' — for example, a merchant holding permissionIndex can still submit someone else's credentials.",
+          "scenario": "In-permission forgery: an authorized operator submits someone else's data (e.g. someone else's Merkle Root)",
+          "mitigation": "1) If the submitted data should belong to the operator (e.g. the operator's address), it is still recommended to add context(Signer) binding;2) If the submitted data is a public credential (e.g. Merkle Root string), the current risk is acceptable;3) Use retained_submission to retain submitted data for later audit",
+          "stakeholders": ["customer", "provider"]
+        },
+        {
+          "when": { "all": [{ "field": "has_submission", "op": "eq", "value": true }, { "field": "scene_binding_field", "op": "neq", "value": "voting_guard" }, { "field": "rc3_01_sharing_exempt", "op": "eq", "value": false }, { "field": "has_signer_check", "op": "eq", "value": false }] },
+          "level": "high",
+          "title": "Submitted data not bound to signer identity",
+          "description": "Guard accepts runtime-submitted data (b_submission=true), but does not verify whether the submitter is the current transaction signer.An attacker can submit someone else's data (e.g. someone else's address, someone else's credentials) to pass the Guard.Type3 submitted objects are isomorphic with Type1 at the native layer (TYPE_QUERY+TYPE_CONSTANT), the only difference being that the value is injected by submission, so identity must be bound via logical constraints.",
+          "scenario": "Identity forgery: attacker submits someone else's address to impersonate an authorized user",
+          "mitigation": "1) Add context(Signer) binding with the submitted data for verification;2) Use vec_contains_address to verify the signer is in the whitelist;3) Use Passport credentials instead of bare address submission",
+          "stakeholders": ["customer", "provider"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "An attacker who passes the unbound Guard exercises the operation it gates as if authorized — the project's funds and objects are exposed to unauthorized execution." },
+              { "role": "buyer", "basis": "Forged submissions can push the buyer's order through states the buyer never authorized." }
+            ],
+            "gain_paths": [
+              {
+                "role": "neutral",
+                "path": "The attacker submits someone else's address or credential, the unbound check passes, and the gated operation (forward/claim/allocation) executes for the attacker's benefit.",
+                "viability": "viable",
+                "gate": "The Guard verifies submitted values but never ties them to the transaction signer — nothing on-chain blocks the forged-submission pass."
+              }
+            ]
+          }
+        },
+        {
+          "when": { "all": [{ "field": "has_submission", "op": "eq", "value": true }, { "field": "scene_binding_field", "op": "neq", "value": "voting_guard" }, { "field": "rc3_01_sharing_exempt", "op": "eq", "value": false }, { "field": "has_signer_check", "op": "eq", "value": true }] },
+          "level": "low",
+          "title": "Submitted data is indirectly bound via context(Signer) (confirm the binding direction is correct)",
+          "description": "Guard accepts runtime-submitted data, and the root subtree contains a context(Signer) check, forming an indirect binding between submitted data and signer, reducing forgery risk.But manual confirmation is needed: the constant compared with context(Signer) is the correct role (e.g. Provider address rather than Customer address), and the submitted data should indeed be provided by that signer. See R-C4-01 Signer direction risk.",
+          "scenario": "Indirect binding to confirm: whether the Signer check direction matches the submitted data ownership",
+          "mitigation": "1) Confirm context(Signer) is compared with the correct table constant (Provider address rather than Customer address);2) Confirm the source role of the submitted data matches the Signer check;3) For stricter binding, use query to verify the submitter's on-chain identity",
+          "stakeholders": ["customer", "provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-C3-02",
+      "dimension": "submission_forgery",
+      "trigger": "voting_guard weight comes from submitted data without verifying source",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "scene_binding_field", "op": "eq", "value": "voting_guard" }, { "field": "rc3_02_numeric_count", "op": "gt", "value": 0 }] },
+          "level": "critical",
+          "title": "Voting weight comes from user submission and may be forged",
+          "description": "voting_guard weight data comes from table entries with b_submission=true (Type3 submitted values).If the weight is not verified through EntityRegistrar or other trusted sources, a voter can submit arbitrarily high weights to manipulate the voting result.Type3 submitted values are only validated by type byte (value[0]) at the native layer; value range and source are not checked.",
+          "scenario": "Weight forgery: voters submit fake high scores to manipulate the arbitration result",
+          "mitigation": "1) Weights should be queried from EntityRegistrar rather than submitted by users;2) Use query(entity.records) to obtain on-chain registered reputation scores;3) Verify in the Guard that the submitted weight matches the on-chain record",
+          "evidence": "Submitted numeric entries: ${rc3_02_numeric_list}",
+          "stakeholders": ["arbitrator"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "A forged voting weight can swing the arbitration ruling — the buyer may be denied a deserved payout or charged a wrongful one." },
+              { "role": "merchant", "basis": "The same manipulated ruling can force an unjustified compensation payout from the merchant side." }
+            ],
+            "gain_paths": [
+              {
+                "role": "neutral",
+                "path": "A voter submits an arbitrarily high weight in the passport; the voting count consumes the forged value directly.",
+                "viability": "viable",
+                "gate": "Submitted numeric entries are only type-byte validated — no on-chain check ties the weight to a trusted source."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R-C3-03",
+      "dimension": "submission_forgery",
+      "trigger": "Guard contains Address entries with b_submission=true; the runtime submitted object type may not match expectations",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "rc3_03_submitted_addr_count", "op": "gt", "value": 0 }, { "field": "root_has_query", "op": "eq", "value": true }, { "field": "rc3_03_no_type_count", "op": "gt", "value": 0 }] },
+          "level": "medium",
+          "title": "Submitted object missing object_type annotation; runtime type validation relies on native inference",
+          "description": "Guard contains ${rc3_03_submitted_addr_count} Address entries with b_submission=true (Type3 submitted objects).The native layer (passport.rs#parse_table_items) only checks the value[0] type byte for submission; object_type is derived at runtime by wobject_type and does not strictly validate the actual submitted object type.\nWarning: ${rc3_03_no_type_count} entries are missing object_type annotation, semantics are unclear.",
+          "scenario": "Type mismatch: submitting a wrong-typed object causes query to return unexpected values",
+          "mitigation": "1) Annotate object_type for all Address entries with b_submission=true;2) object_type should match the object type expected by the query instruction;3) Indirectly verify the object type via query results in Guard logic (e.g. query order.amount to verify it is an Order)",
+          "evidence": "${rc3_03_evidence}",
+          "stakeholders": ["customer", "provider"]
+        },
+        {
+          "when": { "all": [{ "field": "rc3_03_submitted_addr_count", "op": "gt", "value": 0 }, { "field": "root_has_query", "op": "eq", "value": true }, { "field": "rc3_03_no_type_count", "op": "eq", "value": 0 }] },
+          "level": "low",
+          "title": "Submitted object type validation relies on runtime native inference",
+          "description": "Guard contains ${rc3_03_submitted_addr_count} Address entries with b_submission=true (Type3 submitted objects).The native layer (passport.rs#parse_table_items) only checks the value[0] type byte for submission; object_type is derived at runtime by wobject_type and does not strictly validate the actual submitted object type.\nobject_type is annotated, but still confirm the annotation matches what the query expects.",
+          "scenario": "Type mismatch: submitting a wrong-typed object causes query to return unexpected values",
+          "mitigation": "1) Annotate object_type for all Address entries with b_submission=true;2) object_type should match the object type expected by the query instruction;3) Indirectly verify the object type via query results in Guard logic (e.g. query order.amount to verify it is an Order)",
+          "evidence": "${rc3_03_evidence}",
+          "stakeholders": ["customer", "provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-C3-04",
+      "dimension": "binding_risk",
+      "trigger": "Repository write_guard does not verify id_from_submission type",
+      "cases": [
+        {
+          "when": { "field": "scene_binding_field", "op": "eq", "value": "write_guard" },
+          "level": "high",
+          "title": "Repository write_guard must verify id_from_submission type",
+          "description": "The table entry referenced by Repository write_guard's id_from_submission must be of Address type (Type3 submitted object).The entry referenced by data_from_submission must match the Repository value_type.Type mismatch will cause write failure or data corruption. The write_guard submission contains both id and data parts; the native layer distinguishes them by op_code, but value types must match the table declaration.",
+          "scenario": "Type mismatch: write failure or data corruption",
+          "mitigation": "1) Confirm the entry referenced by id_from_submission has value_type=Address;2) Confirm the entry referenced by data_from_submission has value_type matching the Repository;3) Cover write scenarios in gen_passport tests",
+          "stakeholders": ["provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-C3-05",
+      "dimension": "submission_forgery",
+      "trigger": "Guard accepts a runtime-submitted Order/Progress/Arb object (Type3) but does NOT verify the submitted object belongs to the current project (Machine or Service). The WoWok runtime does NOT enforce any binding between the submitted order_id and the actual Progress being forwarded — the guard verification receives only the caller-provided submission bytes, never the Progress object under advancement. A caller can therefore submit an unrelated order_id from a DIFFERENT project while forwarding a different Progress, causing witness=100 (Order->Progress) to evaluate against foreign data.",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "rc3_05_applies", "op": "eq", "value": true }, { "field": "rc3_05_critical", "op": "eq", "value": true }] },
+          "level": "critical",
+          "title": "Submitted Order/Progress/Arb is NOT verified to belong to the current project (cross-project bypass — CRITICAL trust-boundary gap)",
+          "description": "Guard accepts runtime-submitted Order/Progress/Arb object(s) [${rc3_05_unbound_csv}] but the root does NOT verify the submitted object belongs to the current project (no query of order.service/order.machine/progress.machine/arb.service compared to a project constant).\n\nTRUST-BOUNDARY GAP (verified via Move source):\n  - The Passport submission is built by the CALLER, not auto-injected by the runtime\n  - the guard verification receives ONLY the caller-provided submission bytes — it never sees the Progress/Order actually being forwarded\n  - the passport-driven forward performs NO linkage check between the passport submission and the Progress under advancement\n  - Even the order forward's E_ORDER_NOT_MATCH only checks the separate `order:&Order` parameter, NOT the order_id embedded in the passport submission\n\nEXPLOIT (scene=${rc3_05_scene_label}):\n  1. Attacker holds Order Y from project B (where progress.current_time is old enough to pass the time-lock)\n  2. Attacker calls forward on Order X's Progress (project A, freshly entered the node)\n  3. Attacker submits Order Y's ID in the passport (lying about which order is being forwarded)\n  4. Guard's witness=100 reads Order Y's Progress -> time-lock passes (Order Y is old)\n  5. forward actually executes on Order X's Progress -> TIME-LOCK BYPASSED\n\nThis is distinct from R-C3-01 (Signer binding — WHO can submit) and R-C3-03 (type matching — WHAT type is submitted). R-C3-05 addresses WHETHER the submitted object belongs to the current project — a third orthogonal axis of submission trust. Even with R-C3-01 satisfied (authorized Signer) and R-C3-03 satisfied (correct type), the Signer can still submit an unrelated project's object.",
+          "scenario": "Cross-project bypass: authorized signer submits an unrelated project's order/progress/arb to bypass time-lock, status, or allocation conditions",
+          "mitigation": "Add a project-binding check to the root (wrap existing root in logic_and):\n  - For submitted Order: add logic_equal[query(1563: order.service), identifier[N](project_service_address)] — RECOMMENDED (service is the canonical project anchor)\n  - For submitted Order: add logic_equal[query(1560: order.machine), identifier[N](project_machine_address)] — alternative (machine anchor)\n  - For submitted Progress: add logic_equal[query(1250: progress.machine), identifier[N](project_machine_address)]\n  - For submitted Arb: add logic_equal[query(1402: arb.service), identifier[N](project_service_address)]\n  - Use witness=102 (TypeOrderService) on the submitted Order to derive the Service, then compare to the project service constant\n\nIntentional cross-project exception: if the Guard is DESIGNED to accept cross-project submissions (rare), document this explicitly in the description and add a binding_hint annotation 'cross_project_intentional:true' to suppress this rule.",
+          "evidence": "Unbound submitted project-relevant entries: ${rc3_05_unbound_csv}. Scene: ${rc3_05_scene_label}. Missing project-binding queries: none of [1563(order.service), 1560(order.machine), 1250(progress.machine), 1402(arb.service)] present in root.",
+          "stakeholders": ["customer", "provider", "arbitrator"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "Time-lock, status and allocation conditions stop protecting the project — funds can be released before the merchant's obligations are met." },
+              { "role": "buyer", "basis": "The buyer's order protections (time-locks, status gates) can be bypassed with a foreign project's object." }
+            ],
+            "gain_paths": [
+              {
+                "role": "neutral",
+                "path": "The caller submits an unrelated project's order/progress id in the passport while forwarding the real Progress; the Guard witness reads the foreign object and passes.",
+                "viability": "viable",
+                "gate": "The runtime never links the passport submission to the Progress under advancement — the bypass executes exactly as described in the exploit."
+              }
+            ]
+          }
+        },
+        {
+          "when": { "all": [{ "field": "rc3_05_applies", "op": "eq", "value": true }, { "field": "rc3_05_critical", "op": "eq", "value": false }] },
+          "level": "high",
+          "title": "Submitted Order/Progress/Arb is NOT verified to belong to the current project (cross-project bypass — CRITICAL trust-boundary gap)",
+          "description": "Guard accepts runtime-submitted Order/Progress/Arb object(s) [${rc3_05_unbound_csv}] but the root does NOT verify the submitted object belongs to the current project (no query of order.service/order.machine/progress.machine/arb.service compared to a project constant).\n\nTRUST-BOUNDARY GAP (verified via Move source):\n  - The Passport submission is built by the CALLER, not auto-injected by the runtime\n  - the guard verification receives ONLY the caller-provided submission bytes — it never sees the Progress/Order actually being forwarded\n  - the passport-driven forward performs NO linkage check between the passport submission and the Progress under advancement\n  - Even the order forward's E_ORDER_NOT_MATCH only checks the separate `order:&Order` parameter, NOT the order_id embedded in the passport submission\n\nEXPLOIT (scene=${rc3_05_scene_label}):\n  1. Attacker holds Order Y from project B (where progress.current_time is old enough to pass the time-lock)\n  2. Attacker calls forward on Order X's Progress (project A, freshly entered the node)\n  3. Attacker submits Order Y's ID in the passport (lying about which order is being forwarded)\n  4. Guard's witness=100 reads Order Y's Progress -> time-lock passes (Order Y is old)\n  5. forward actually executes on Order X's Progress -> TIME-LOCK BYPASSED\n\nThis is distinct from R-C3-01 (Signer binding — WHO can submit) and R-C3-03 (type matching — WHAT type is submitted). R-C3-05 addresses WHETHER the submitted object belongs to the current project — a third orthogonal axis of submission trust. Even with R-C3-01 satisfied (authorized Signer) and R-C3-03 satisfied (correct type), the Signer can still submit an unrelated project's object.",
+          "scenario": "Cross-project bypass: authorized signer submits an unrelated project's order/progress/arb to bypass time-lock, status, or allocation conditions",
+          "mitigation": "Add a project-binding check to the root (wrap existing root in logic_and):\n  - For submitted Order: add logic_equal[query(1563: order.service), identifier[N](project_service_address)] — RECOMMENDED (service is the canonical project anchor)\n  - For submitted Order: add logic_equal[query(1560: order.machine), identifier[N](project_machine_address)] — alternative (machine anchor)\n  - For submitted Progress: add logic_equal[query(1250: progress.machine), identifier[N](project_machine_address)]\n  - For submitted Arb: add logic_equal[query(1402: arb.service), identifier[N](project_service_address)]\n  - Use witness=102 (TypeOrderService) on the submitted Order to derive the Service, then compare to the project service constant\n\nIntentional cross-project exception: if the Guard is DESIGNED to accept cross-project submissions (rare), document this explicitly in the description and add a binding_hint annotation 'cross_project_intentional:true' to suppress this rule.",
+          "evidence": "Unbound submitted project-relevant entries: ${rc3_05_unbound_csv}. Scene: ${rc3_05_scene_label}. Missing project-binding queries: none of [1563(order.service), 1560(order.machine), 1250(progress.machine), 1402(arb.service)] present in root.",
+          "stakeholders": ["customer", "provider", "arbitrator"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "Time-lock, status and allocation conditions stop protecting the project — funds can be released before the merchant's obligations are met." },
+              { "role": "buyer", "basis": "The buyer's order protections (time-locks, status gates) can be bypassed with a foreign project's object." }
+            ],
+            "gain_paths": [
+              {
+                "role": "neutral",
+                "path": "The caller submits an unrelated project's order/progress id in the passport while forwarding the real Progress; the Guard witness reads the foreign object and passes.",
+                "viability": "viable",
+                "gate": "The runtime never links the passport submission to the Progress under advancement — the bypass executes exactly as described in the exploit."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R-C3-06",
+      "dimension": "binding_risk",
+      "trigger": "Guard is bound to Service order_allocators (service_order_allocators_guard scene). In this scene the Guard decides IF allocation happens, while sharing.who decides WHERE funds go. If sharing.who=Signer, the transaction caller receives the funds — so a Guard that does NOT bind context(Signer) lets ANYONE who passes the Guard steal 100% of the order funds. This is a Guard+sharing coupling risk: neither piece alone reveals the theft — only their combination.",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "rc3_06_applies", "op": "eq", "value": true }, { "field": "rc3_06_signer_sharing", "op": "eq", "value": true }] },
+          "level": "critical",
+          "title": "allocators Guard without Signer binding — ${rc3_06_title_suffix}",
+          "description": "Guard is bound to Service order_allocators but does NOT verify context(Signer). In the allocators scene, sharing.who determines the fund recipient:\n  - sharing.who=Signer → funds flow to the CALLER (transaction signer)\n  - sharing.who=Entity → funds flow to a FIXED address (Treasury/personal)\n  - sharing.who=GuardIdentifier → funds flow to the submitted constrained object (e.g. an Order), receivable only by that object's owner (object receipt = owner receipt); see RC-FIND-03 residual in the recipient constraint audit\n\nWhen sharing.who=Signer and the Guard does not bind Signer, ANY caller who passes the Guard receives the order funds — a direct theft. Even an authorized caller is unnecessary: the attacker only needs to pass the Guard's condition (e.g. submit any completed order_id), then the funds go to their own address.\n\nThis is distinct from R-C3-01 (generic Signer binding) and R-C3-05 (cross-project bypass). R-C3-06 addresses the allocators-specific Guard+sharing coupling: the SAFE design uses sharing.who=Entity so the recipient is fixed, making Guard Signer binding unnecessary.\n\nsharing_recipients hint: ${rc3_06_recipients_label}",
+          "scenario": "Fund theft: attacker passes the allocators Guard (e.g. submits a completed order_id) and sharing.who=Signer routes 100% of the order funds to the attacker's address",
+          "mitigation": "TWO mitigation options:\n  (A) Traditional: add context(Signer) binding to the Guard root (logic_equal[context(Signer), identifier[N](authorized_address)]) so only the authorized recipient can trigger allocation.\n  (B) PREFERRED: use sharing.who=Entity (Treasury object or fixed personal address) in the Allocator's sharing config. Funds then always flow to the designated recipient regardless of who triggers allocation — the Guard does NOT need to bind Signer. This is more robust because it does not depend on Guard correctness.\n\nDesign checklist when using sharing.who=Entity:\n  - If Entity points to a Treasury object, verify the Treasury's permission is consistent with the Service's permission (different permissions = different permission organizations = minor risk).\n  - allocators require unique guard addresses: create separate Guard objects (identical root/table, different descriptions) for each allocator.\n  - First-match-wins: only the first Allocator whose Guard passes executes; multiple allocators represent alternative strategies, not a simultaneous split.\n  - Still add order.service project binding (query 1563) to prevent cross-project bypass (R-C3-05) triggering premature allocation.",
+          "evidence": "Scene: service_order_allocators_guard. Guard binds Signer: no. sharing_recipients: ${rc3_06_recipients_label}. Level rationale: ${rc3_06_level_rationale}.",
+          "stakeholders": ["provider", "customer"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "The order's full fund allocation can be redirected away from the configured recipients on the very first qualifying call." },
+              { "role": "buyer", "basis": "The buyer's payment is distributed to an attacker instead of the intended revenue/refund split." }
+            ],
+            "gain_paths": [
+              {
+                "role": "neutral",
+                "path": "Any caller who passes the allocators Guard (e.g. submits any completed order_id) triggers the allocation; sharing.who=Signer routes 100% of the order funds to the caller's own address.",
+                "viability": "viable",
+                "gate": "The Guard never compares context(Signer) to an authorized party, so passing the Guard's condition is the only requirement — the theft path is executable by anyone."
+              }
+            ]
+          }
+        },
+        {
+          "when": { "all": [{ "field": "rc3_06_applies", "op": "eq", "value": true }, { "field": "rc3_06_signer_sharing", "op": "eq", "value": false }] },
+          "level": "medium",
+          "title": "allocators Guard without Signer binding — ${rc3_06_title_suffix}",
+          "description": "Guard is bound to Service order_allocators but does NOT verify context(Signer). In the allocators scene, sharing.who determines the fund recipient:\n  - sharing.who=Signer → funds flow to the CALLER (transaction signer)\n  - sharing.who=Entity → funds flow to a FIXED address (Treasury/personal)\n  - sharing.who=GuardIdentifier → funds flow to the submitted constrained object (e.g. an Order), receivable only by that object's owner (object receipt = owner receipt); see RC-FIND-03 residual in the recipient constraint audit\n\nWhen sharing.who=Signer and the Guard does not bind Signer, ANY caller who passes the Guard receives the order funds — a direct theft. Even an authorized caller is unnecessary: the attacker only needs to pass the Guard's condition (e.g. submit any completed order_id), then the funds go to their own address.\n\nThis is distinct from R-C3-01 (generic Signer binding) and R-C3-05 (cross-project bypass). R-C3-06 addresses the allocators-specific Guard+sharing coupling: the SAFE design uses sharing.who=Entity so the recipient is fixed, making Guard Signer binding unnecessary.\n\nsharing_recipients hint: ${rc3_06_recipients_label}",
+          "scenario": "Fund theft: attacker passes the allocators Guard (e.g. submits a completed order_id) and sharing.who=Signer routes 100% of the order funds to the attacker's address",
+          "mitigation": "TWO mitigation options:\n  (A) Traditional: add context(Signer) binding to the Guard root (logic_equal[context(Signer), identifier[N](authorized_address)]) so only the authorized recipient can trigger allocation.\n  (B) PREFERRED: use sharing.who=Entity (Treasury object or fixed personal address) in the Allocator's sharing config. Funds then always flow to the designated recipient regardless of who triggers allocation — the Guard does NOT need to bind Signer. This is more robust because it does not depend on Guard correctness.\n\nDesign checklist when using sharing.who=Entity:\n  - If Entity points to a Treasury object, verify the Treasury's permission is consistent with the Service's permission (different permissions = different permission organizations = minor risk).\n  - allocators require unique guard addresses: create separate Guard objects (identical root/table, different descriptions) for each allocator.\n  - First-match-wins: only the first Allocator whose Guard passes executes; multiple allocators represent alternative strategies, not a simultaneous split.\n  - Still add order.service project binding (query 1563) to prevent cross-project bypass (R-C3-05) triggering premature allocation.",
+          "evidence": "Scene: service_order_allocators_guard. Guard binds Signer: no. sharing_recipients: ${rc3_06_recipients_label}. Level rationale: ${rc3_06_level_rationale}.",
+          "stakeholders": ["provider", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-C4-01",
+      "dimension": "system_context_risk",
+      "trigger": "Guard contains context(Signer) check; need to confirm comparison direction (== vs !=) and compared object role",
+      "cases": [
+        {
+          "when": { "field": "has_signer_check", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Signer check direction needs manual confirmation (comparison operator and role match)",
+          "description": "Guard contains a context(Signer) check. Signer is a Type4 system context, from TransactionContext.sender() (transaction initiator address).\nDetected comparison: ${rc4_01_comparison_detail}\nManual confirmation required:\n  1) Whether the comparison direction is correct: use == for identity verification (Signer == authorized address), use != for exclusion (Signer != blacklist address)\n  2) Whether the compared object role is correct: buy_guard should compare the Customer address, Forward.guard may compare the Provider address\n  3) Wrong direction causes reverse effect: == blacklist address would only allow blacklisted users",
+          "scenario": "Wrong direction: Signer == blacklist address would only allow blacklisted users",
+          "mitigation": "1) Confirm logic_equal is used for identity verification (Signer == authorized address);2) Confirm logic_not_equal is used for exclusion (Signer != blacklist address);3) Confirm the compared table constant is the address of the correct role;4) Cover both expected-pass and expected-fail scenarios in gen_passport tests",
+          "evidence": "Comparison: ${rc4_01_comparison_ops}",
+          "stakeholders": ["customer", "provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-C4-02",
+      "dimension": "system_context_risk",
+      "trigger": "Guard uses context(Clock) for precise boundary time-lock comparison",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "has_clock_check", "op": "eq", "value": true }, { "any": [{ "field": "rc4_02_has_greater_or_equal", "op": "eq", "value": true }, { "field": "rc4_02_has_greater", "op": "eq", "value": true }] }] },
+          "level": "low",
+          "title": "Clock time-lock should have tolerance to avoid boundary invalidation from validator block-time variance",
+          "description": "Guard uses context(Clock) for time-lock comparison. Clock comes from the timestamp_ms field (U64 millisecond timestamp) of system shared object 0x6.The Wow on-chain timestamp is produced by validator consensus and has a slight deviation from real time (usually < 1 second), and block-time variance may cause timestamp jumps. Using precise boundaries (>= or ==) may cause:\n  - The time-lock expiration transaction is packaged exactly at the moment but fails due to slight timestamp deviation\n  - Or conversely, slight deviation causes the time-lock to pass early\nIt is recommended to use > instead of >=, or add a small tolerance constant.",
+          "scenario": "Timestamp variance: validator block-time deviation causes boundary transactions to fail or pass early",
+          "mitigation": "1) Use logic_as_u256_greater (>) instead of greater_or_equal (>=) for expiration judgment;2) Or add a small tolerance constant (e.g. 1000ms) in calc_number_add;3) Time-locks should not rely on second-level precision; reserve minute-level tolerance;4) Design timeout Forward nodes in the Machine as a fallback",
+          "evidence": "Comparison: ${rc4_02_comparison_ops}",
+          "stakeholders": ["customer", "provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-C4-03",
+      "dimension": "system_context_risk",
+      "trigger": "Guard uses context(Guard) self-reference",
+      "cases": [
+        {
+          "when": { "field": "has_guard_self_ref", "op": "eq", "value": true },
+          "level": "low",
+          "title": "Guard uses context(Guard) self-reference (rare scenario, needs special explanation)",
+          "description": "Guard contains a context(Guard) node. Guard is a Type4 system context, returning the ObjectID of the currently verified Guard object itself.\nThis is a rare scenario, typically used for:\n  1) Guard referencing its own address as a replacement for a table constant (avoiding hardcoding)\n  2) Identifying the current Guard in a rely combination (rare)\nNeed to confirm whether the use of context(Guard) is necessary and whether the comparison object is correct.",
+          "scenario": "Self-reference misuse: context(Guard) comparing wrong object causes logic invalidation",
+          "mitigation": "1) Confirm the context(Guard) comparison object is the Guard ObjectID rather than an address constant;2) Evaluate whether self-reference is truly needed; usually a table constant can replace it;3) Verify in gen_passport tests that self-reference behavior meets expectations",
+          "stakeholders": ["provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-C4-04",
+      "dimension": "system_context_risk",
+      "trigger": "Guard uses logic_equal[context(Signer), identifier[N](fixed_address)] — Level 1 strict single-identity Signer binding. Only ONE address can pass the Guard, and because Guards are immutable, changing the authorized address requires rebuilding the Guard and migrating all references. This creates a convenience trade-off: maximum security but maximum inflexibility (key loss or personnel change permanently blocks the operation).",
+      "cases": [
+        {
+          "when": { "field": "rc4_04_detected", "op": "eq", "value": true },
+          "level": "low",
+          "title": "Level 1 strict single-identity Signer binding — convenience trade-off (consider Level 2/3 alternatives)",
+          "description": "Guard uses logic_equal[context(Signer), identifier[${rc4_04_entry_identifier}](fixed address)] — only the address \"${rc4_04_entry_value}\" can pass.\nThis is Level 1 strict single-identity binding: maximally secure but maximally inconvenient.\nGuards are immutable on-chain. If the authorized address becomes unavailable (key loss, personnel change, role rotation), the Guard permanently blocks the operation — the only recovery is to build a new Guard and migrate ALL references (Machine forward guards, Service buy_guard, allocators, etc.).\n\nThree verifier constraint levels trade off security vs convenience:\n  - Level 1 (current): strict single-identity — one address, no flexibility (AVOID unless justified)\n  - Level 2: identity-set — logic_or of multiple valid identities (e.g. order.owner OR order.agent; permission.owner OR permission.admin). Recommended for role-based access.\n  - Level 3: scene-combined — verify whether Signer binding is even needed. Many scenes (allocators with sharing.who=Entity, machine forward with permissionIndex) already ensure safety without Signer binding.\n\nUse Level 1 only when: (a) the role is permanently tied to one address, AND (b) the designer explicitly accepts the immutability lock-in risk. Otherwise prefer Level 2 or Level 3.",
+          "scenario": "Immutability lock-in: authorized address becomes unavailable, Guard permanently blocks the operation, requiring full Guard rebuild and reference migration",
+          "mitigation": "Consider these alternatives before settling on Level 1 strict binding:\n  (A) Level 2 identity-set (RECOMMENDED for role-based access): use logic_or to allow multiple valid identities.\n      - Order holder: logic_or[logic_equal[query(1562: order.owner), context(Signer)], query(1567: order.agent has, parameters: [context(Signer)])]\n      - Service provider: logic_or[logic_equal[query(1002: permission.owner), context(Signer)], query(1004: permission.admin has, parameters: [context(Signer)])]\n      - Dynamic permission (survives rotation): submit permission address, verify query(1488: service.permission) == submitted, then check 1002/1004\n  (B) Level 3 scene-combined: evaluate whether Signer binding is needed at all.\n      - If using allocators with sharing.who=Entity (Treasury): funds flow to a fixed recipient regardless of caller — no Signer binding needed (R-C3-06 safe)\n      - If using machine forward: permissionIndex already verifies operator identity — Signer binding may be redundant\n  (C) If Level 1 is truly required: document the justification in the Guard description and ensure a key-recovery / address-rotation plan exists.",
+          "evidence": "Level 1 strict binding detected: logic_equal[context(Signer), identifier[${rc4_04_entry_identifier}]] where identifier[${rc4_04_entry_identifier}] is a fixed Address constant (${rc4_04_entry_detail}). Not wrapped in logic_or (not Level 2 identity-set).",
+          "stakeholders": ["provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-01",
+      "dimension": "logic_gap",
+      "trigger": "Time-lock uses logic_as_u256_greater_or_equal with a baseline query that has NO non-zero invariant (i.e. the query MAY legitimately return 0 when it succeeds), causing Clock >= 0 + timeout to always be true",
+      "cases": [
+        {
+          "when": { "field": "rx1_01_trigger", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Time-lock baseline query may return 0 causing >= comparison to always be true",
+          "description": "Guard uses logic_as_u256_greater_or_equal for time-lock comparison, and the compared baseline value comes from a query (Type1/2/3 data sources). If the query SUCCEEDS but its stored value is 0 (e.g. a count that is 0 in the empty initial state, a user-submitted value of 0, or a Some(0) from an Option field), then Clock >= 0 + timeout is always true, the time-lock is effectively void, and the disadvantaged party can bypass the time constraint immediately.\n\nIMPORTANT — 'VM error = Guard failure' baseline: if a query targets an absent object, unset Option, or missing collection entry, the WoWok native runtime aborts with a VM error (e.g. W_FIELD_NOT_FOUND) and the Guard fails as a whole (does NOT silently return 0). Therefore the null-bypass risk ONLY applies to queries whose stored value can legitimately be 0 while the query itself succeeds. Such queries are exactly those WITHOUT an `invariant` annotation in the SDK GUARDQUERY catalog.",
+          "scenario": "Time-lock invalidation: baseline query returns 0 (not VM error), making the >= condition always pass",
+          "mitigation": "1) Use a query whose return is guaranteed non-zero (look for `invariant` in guard-ins.ts — e.g. progress.current_time id=1272 with invariant='clock_derived'); 2) Add a precondition check query > 0 before the time-lock (for queries without an invariant, e.g. user-submitted baselines); 3) Avoid using count/index/find/user-submitted values as time-lock baselines — these can all legitimately return 0; 4) Distinguish 'VM error' (safe — Guard fails) from 'query returns 0' (unsafe — Guard bypassed). Only the latter is a null-bypass risk.",
+          "evidence": "${rx1_01_evidence}",
+          "stakeholders": ["customer", "provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-02",
+      "dimension": "logic_gap",
+      "trigger": "Guard uses logic_as_u256_greater with a query operand that has NO non-zero invariant (i.e. the query MAY legitimately return 0 when it succeeds), and the comparison does not distinguish 'query succeeded with 0' from 'query failed'",
+      "cases": [
+        {
+          "when": { "field": "rx1_02_trigger", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Numeric comparison with a query that may legitimately return 0",
+          "description": "Guard uses logic_as_u256_greater for numeric comparison, and one of the operands comes from a query (Type1/2/3 data sources) that has NO non-zero invariant annotation. If the query SUCCEEDS but its stored value is 0 (e.g. a count that is 0 in the empty initial state, a user-submitted value of 0, or a Some(0) from an Option field), the comparison may produce an unexpected result (e.g. `query > 0` fails, or `query > some_threshold` is silently bypassed).\n\nIMPORTANT — 'VM error = Guard failure' baseline: if a query targets absent data (e.g. object does not exist, Option is None, collection entry is missing), the WoWok native runtime aborts with a VM error (not 0). The Guard fails as a whole (does NOT silently return 0). Therefore this rule only flags queries whose stored value can be 0 while the query succeeds.",
+          "scenario": "Null misjudgment: query succeeds with value 0, causing > 0 condition to unexpectedly fail (or > threshold to be bypassed)",
+          "mitigation": "1) Prefer queries with an `invariant` annotation (e.g. clock_derived / positive_lower_bound); 2) Add a precondition check (query > 0) before the main comparison when using count/index/find/user-submitted baselines; 3) Distinguish 'VM error' (safe — Guard fails) from 'query returns 0' (potentially unsafe). Only the latter is a null-bypass risk.",
+          "evidence": "${rx1_02_evidence}",
+          "stakeholders": ["customer", "provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-03",
+      "dimension": "logic_gap",
+      "trigger": "Guard uses logic_string_contains and may be bypassed by substring matching",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "root_has_logic_string_contains", "op": "eq", "value": true }, { "field": "root_has_logic_string_nocase", "op": "eq", "value": false }] },
+          "level": "low",
+          "title": "logic_string_contains substring match may be bypassed",
+          "description": "Guard uses logic_string_contains for string matching.Substring matching may be bypassed: e.g. when checking 'Completed', 'NotCompleted' also contains 'Completed'.In addition, case sensitivity may cause unexpected failures. String data may come from Type1 (query object fields), Type3 (submitted values), or the context of a rely-dependent Guard.",
+          "scenario": "Substring mismatch: 'NotCompleted' contains 'Completed', causing false pass",
+          "mitigation": "1) Prefer logic_equal for exact matching;2) If substring matching is needed, add boundary conditions (e.g. prefix + suffix);3) Confirm whether case-insensitivity is needed (use the nocase variant)",
+          "stakeholders": ["customer", "provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-04",
+      "dimension": "logic_gap",
+      "trigger": "Guard root is an identifier directly returning Bool",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "root_is_identifier", "op": "eq", "value": true }, { "field": "root_identifier_is_submission", "op": "eq", "value": true }] },
+          "level": "medium",
+          "title": "Root directly returns identifier value, no operation logic",
+          "description": "Guard root is an identifier node, directly returning the value (Bool) from table.This entry has b_submission=true (Type3 submitted value); the caller can directly submit true to bypass all verification.",
+          "scenario": "Bypass verification: caller submits true to pass the Guard directly",
+          "mitigation": "1) Ensure the entry referenced by identifier has b_submission=false (constant);2) Or add an additional logic_and condition for cross-validation",
+          "stakeholders": ["customer", "provider"]
+        },
+        {
+          "when": { "all": [{ "field": "root_is_identifier", "op": "eq", "value": true }, { "field": "root_identifier_is_submission", "op": "eq", "value": false }] },
+          "level": "low",
+          "title": "Root directly returns identifier value, no operation logic",
+          "description": "Guard root is an identifier node, directly returning the value (Bool) from table.This entry has b_submission=false (Type1 constant); the value is fixed but the Guard has no actual verification logic.",
+          "scenario": "No verification logic: Guard always returns a fixed value, providing no actual protection",
+          "mitigation": "1) Add actual verification logic (query + logic comparison);2) Evaluate whether this Guard needs to exist",
+          "stakeholders": ["customer", "provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-05",
+      "dimension": "game_theory",
+      "trigger": "Allocation Guard may cause some participants to be skipped",
+      "cases": [
+        {
+          "when": { "field": "scene_binding_field", "op": "eq", "value": "order_allocators" },
+          "level": "medium",
+          "title": "order_allocators first-match-wins may cause unfair allocation",
+          "description": "order_allocators uses a first-match-wins strategy: the first Allocator whose Guard passes executes the allocation.If the order is poorly designed, some participants may never get allocated.For example: if the first Allocator's Guard condition is too broad, subsequent more precise Allocators will never execute.Allocation Guards typically combine Type1 (query order fields), Type3 (submit Order address), and Type4 (Signer) data.",
+          "scenario": "Allocation skip: the Provider's allocation Allocator is skipped by preceding broad conditions",
+          "mitigation": "1) Ensure the order_allocators order goes from strict to loose;2) Each Allocator's Guard conditions should be mutually exclusive;3) Consider using logic_or dependencies rather than sequential ordering",
+          "stakeholders": ["provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-06",
+      "dimension": "game_theory",
+      "trigger": "Workflow Guard time-lock may lock the disadvantaged party",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "root_has_clock_token", "op": "eq", "value": true }, { "field": "root_has_calc_number_add", "op": "eq", "value": true }] },
+          "level": "medium",
+          "title": "Time-lock may lock the disadvantaged party",
+          "description": "Guard uses a time-lock (context(Clock) + calc_number_add). The time-lock itself is neutral, but the locking direction needs to be checked: if the Customer is locked to pay first but cannot accept in time, the Provider gains advantage; if the Provider is locked to deliver first but cannot receive payment in time, the Customer gains advantage.The time-lock combines Type4 (Clock) and Type1/2 (query time fields) data sources.",
+          "scenario": "Time asymmetry: one party is locked by time while the other has freedom of action",
+          "mitigation": "1) Ensure the time-lock is symmetric (both parties have time constraints);2) Provide an exit mechanism after the time-lock expires (e.g. auto-refund/auto-complete);3) Design corresponding timeout Forward nodes in the Machine",
+          "stakeholders": ["customer", "provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-07",
+      "dimension": "game_theory",
+      "trigger": "Arbitration usage_guard may block legitimate disputes",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "scene_binding_field", "op": "eq", "value": "usage_guard" }, { "field": "logic_and_count", "op": "gte", "value": 3 }] },
+          "level": "high",
+          "title": "usage_guard has too many conditions and may block legitimate disputes",
+          "description": "Detected ${logic_and_count} logic_and combinations. Too many AND conditions make the dispute threshold too high, the Customer may not be able to initiate a legitimate dispute, and the Provider gains an unfair advantage.usage_guard typically combines Type4 (Signer identity), Type3 (submit Passport credentials), and Type1 (query EntityRegistrar verification) data sources.",
+          "scenario": "Dispute threshold too high: Customer cannot initiate a legitimate dispute",
+          "mitigation": "1) Re-evaluate the necessity of each AND condition;2) Consider using logic_or to lower the threshold;3) Move non-essential conditions to voting_guard rather than usage_guard",
+          "stakeholders": ["customer"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "The dispute entry threshold is stacked so high that a legitimate dispute cannot be initiated — the buyer's compensation path becomes inaccessible." }
+            ],
+            "gain_paths": []
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-08",
+      "dimension": "binding_risk",
+      "trigger": "Guard is bound to a published Machine/Service (immutable)",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "scene_present", "op": "eq", "value": true }, { "field": "scene_mutable_after_publish", "op": "falsy" }] },
+          "level": "low",
+          "title": "Guard is bound to immutable ${scene_host_object} (cannot be modified after publish)",
+          "description": "After ${scene_host_object} is published, ${scene_binding_field} cannot be modified.If the Guard design is flawed, a new Machine/Service must be created and all references migrated.This is a design constraint rather than a risk, but the Guard design must be correct before publishing.",
+          "scenario": "Irreversible binding: after publish, a flawed Guard design cannot be modified",
+          "mitigation": "1) Use gen_passport for thorough testing before publishing;2) Test both expected-pass and expected-fail scenarios;3) Export a Guard backup (guard2file) before publishing",
+          "stakeholders": ["provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-09",
+      "dimension": "dependency_risk",
+      "trigger": "Guard uses rely but the dependent Guard may fail",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "rely_guards_count", "op": "gt", "value": 0 }, { "field": "rely_is_or", "op": "eq", "value": true }] },
+          "level": "low",
+          "title": "rely ${rely_logic} depends on ${rely_guards_count} external Guards",
+          "description": "Guard uses rely ${rely_logic} to depend on ${rely_guards_count} external Guards.OR logic: any one passing is enough. If a dependent Guard is loosely designed, it may become a bypass entry point. rely-dependent Guards must have rep=true (repository.data queries do not depend on runtime submission).",
+          "scenario": "Dependency bypass: a loose dependent Guard becomes an attack entry point",
+          "mitigation": "1) Review the strictness of each dependent Guard; 2) Ensure all dependent Guards are at least as strict as the current Guard",
+          "stakeholders": ["customer", "provider"]
+        },
+        {
+          "when": { "all": [{ "field": "rely_guards_count", "op": "gt", "value": 0 }, { "field": "rely_is_or", "op": "eq", "value": false }] },
+          "level": "medium",
+          "title": "rely ${rely_logic} depends on ${rely_guards_count} external Guards",
+          "description": "Guard uses rely ${rely_logic} to depend on ${rely_guards_count} external Guards.AND logic: all dependencies must pass. If a dependent Guard fails or is deleted, the current Guard will always fail. rely-dependent Guards must have rep=true (repository.data queries do not depend on runtime submission).",
+          "scenario": "Dependency failure: a dependent Guard is deleted, causing the current Guard to always fail",
+          "mitigation": "1) Confirm all dependent Guards have rep=true and cannot be deleted; 2) Consider whether AND dependency is truly needed",
+          "stakeholders": ["customer", "provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-10",
+      "dimension": "impack_risk",
+      "trigger": "Guard uses repository.data query (query 1167) and the Repository has quote_guard set — rigid verification requirement",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "queries_repository", "op": "eq", "value": true }, { "field": "root_has_query", "op": "eq", "value": true }] },
+          "level": "low",
+          "title": "repository.data quote_guard is a RIGID verification requirement (data subscription access control)",
+          "description": "When a Guard queries repository.data (query 1167), if the Repository policy has quote_guard set (Some(addr)), then the quote_guard MUST be verified. This is a RIGID requirement — not context-dependent.\n\nTWO-PHASE VERIFICATION MECHANISM (VERIFIED: passport.rs#L756-769, passport.rs#L545-612):\n  Phase 1 — Passport generation (scan guard): The system scans the Guard to identify that it queries repository data. If the Repository has a quote_guard, the system prepares the quote_guard for verification (adds it to the required verification set, populating impack_list).\n  Phase 2 — Passport verification: The system re-checks (a) is the quote_guard prepared/in impack_list? (b) rigidly verify the quote_guard (e.g., verify Payment proof for subscription).\n\nSEMANTIC INTENT: Any Guard that uses a Repository's data MUST satisfy that Repository's quote_guard. This is the intended access control mechanism for data subscription — e.g., accessing weather data requires payment proof verified by the quote_guard.\n\nDESIGN PHILOSOPHY: On-chain data is consumed by guard verifiers. The quote_guard gates Repository data access, enabling subscription revenue models. The Guard only verifies logic + data accuracy (verifier-evidence design).",
+          "scenario": "quote_guard rigid verification: any guard querying repository data must satisfy the repository's quote_guard (e.g., payment requirement)",
+          "mitigation": "1) This is an INTENDED capability, not a limitation — quote_guard enables data subscription access control;\n2) When designing a Guard that queries Repository data with quote_guard: ensure the Passport includes the quote_guard verification with necessary submissions (e.g., Payment proof);\n3) Pattern: Repository with quote_guard for data subscription — quote_guard verifies Payment (for_object, for_guard, index), user submits Payment via Passport, quote_guard verified in both phases, repository data query passes;\n4) If quote_guard==None: no access control — Repository data is freely queryable",
+          "stakeholders": ["customer", "provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-11",
+      "dimension": "rep_risk",
+      "trigger": "Guard uses rely to depend on other Guards; need to confirm the rep flag of dependent Guards is correct",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "rely_guards_count", "op": "gt", "value": 0 }, { "field": "rx1_11_self_rep_false", "op": "eq", "value": true }] },
+          "level": "medium",
+          "title": "rep semantics needs confirmation (when repository.data query depends on submission, rep=false and cannot be depended on)",
+          "description": "Guard uses rely to depend on external Guards. In the WoWok protocol, rely-dependent Guards must have rep=true.\nPrecise rep semantics (guard.rs#L483-L492): repository.data query (query 1167) does not depend on runtime submission.\n  - rep=true: repository.data query is fully constant-driven (object address b_submission=false and query parameters are not submission)\n  - rep=false: repository address comes from runtime submission, or query parameters come from submission\nGuards with rep=false cannot appear in other Guards' rely lists.\n${rx1_11_warning_tail}",
+          "scenario": "rep misjudgment: depending on a rep=false Guard causes creation failure, or its own rep=false is wrongly depended on",
+          "mitigation": "1) Confirm all rely-dependent Guards have rep=true (do not depend on submission to query repository.data);2) If the current Guard queries repository.data and the address comes from submission, its own rep=false; annotate that it cannot be depended on;3) rep is not 'no Repository dependency', but 'repository.data query does not depend on submission';4) Use wowok_buildin_info to query the full definition of the rep flag",
+          "evidence": "${rx1_11_evidence}",
+          "stakeholders": ["provider"]
+        },
+        {
+          "when": { "all": [{ "field": "rely_guards_count", "op": "gt", "value": 0 }, { "field": "rx1_11_self_rep_false", "op": "eq", "value": false }] },
+          "level": "low",
+          "title": "rep semantics needs confirmation (when repository.data query depends on submission, rep=false and cannot be depended on)",
+          "description": "Guard uses rely to depend on external Guards. In the WoWok protocol, rely-dependent Guards must have rep=true.\nPrecise rep semantics (guard.rs#L483-L492): repository.data query (query 1167) does not depend on runtime submission.\n  - rep=true: repository.data query is fully constant-driven (object address b_submission=false and query parameters are not submission)\n  - rep=false: repository address comes from runtime submission, or query parameters come from submission\nGuards with rep=false cannot appear in other Guards' rely lists.\n${rx1_11_warning_tail}",
+          "scenario": "rep misjudgment: depending on a rep=false Guard causes creation failure, or its own rep=false is wrongly depended on",
+          "mitigation": "1) Confirm all rely-dependent Guards have rep=true (do not depend on submission to query repository.data);2) If the current Guard queries repository.data and the address comes from submission, its own rep=false; annotate that it cannot be depended on;3) rep is not 'no Repository dependency', but 'repository.data query does not depend on submission';4) Use wowok_buildin_info to query the full definition of the rep flag",
+          "evidence": "${rx1_11_evidence}",
+          "stakeholders": ["provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-12",
+      "dimension": "submission_forgery",
+      "trigger": "Guard table contains b_submission=true entries with vague name descriptions or missing binding_constraint",
+      "cases": [
+        {
+          "when": { "field": "rx1_12_vague_count", "op": "gt", "value": 0 },
+          "level": "medium",
+          "title": "Submitted data entry description is vague (retained_submission risk: caller may submit wrong data)",
+          "description": "Guard table has ${rx1_12_vague_count} b_submission=true entries with vague name descriptions.\nThe name of a submission entry is the only data contract between the Guard and the caller.\nIf the name description is unclear (e.g. only 'addr' / 'order_id'), the caller may:\n  - Submit a wrong-typed object address (e.g. submit a Service address instead of an Order address)\n  - Submit a wrong value (e.g. inconsistent amount units)\n  - Confuse submission slots of different Guards in multi-Guard scenarios\nVague submission entries are 'retained' in the table but provide no effective data constraints, equivalent to the Guard accepting arbitrary data without validating its semantic correctness.",
+          "scenario": "Caller submits wrong data due to vague name description; the Guard passes verification but the business logic is wrong",
+          "mitigation": "1) Each submission entry's name should be a complete natural-language description (e.g. 'The order ID that identifies the target Order for verification');\n2) Avoid Technical identifiers as name (e.g. 'order_id' should become 'Order ID, used to query progress status');\n3) Add failure_conditions in binding_hint to clarify failure scenarios;\n4) Consider adding type validation logic in root (e.g. query the submitted object's objectType and match with expectation)",
+          "evidence": "Vague entries: ${rx1_12_vague_csv}",
+          "stakeholders": ["customer", "provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-13",
+      "dimension": "binding_risk",
+      "trigger": "Guard references its host object (Host Object) itself — circular reference pattern",
+      "cases": [
+        {
+          "when": { "field": "rx1_13_detected", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Circular reference pattern (Guard references the host object itself; note creation order)",
+          "description": "In the Guard's table, identifier=${rx1_13_identifier} has object_type equal to the host object type \"${scene_host_object}\".\nCircular reference pattern: the Guard is bound to a Host Object (e.g. Service.buy_guard) and also queries the Host Object's own fields.\nCreation order constraints:\n  1. The Host Object must be created first (unpublished state)\n  2. When the Guard is created, the table uses the Host Object's name (not address); the SDK resolves it at binding time\n  3. After the Guard is bound to the Host Object, the Host Object is published\nRisks:\n  - If the Host Object is already published (immutable), the Guard can no longer be bound\n  - If the Host Object's name is modified after the Guard is created, the Guard's table reference is invalidated\n  - Circular reference makes the Guard not independently testable (the Host Object must exist to verify)",
+          "scenario": "Guard queries fields of the Service/Machine/Reward it is bound to; wrong creation order causes binding failure",
+          "mitigation": "1) Ensure the Host Object is unpublished (bPublished=false) when creating and binding the Guard;\n2) Use the Host Object's name rather than address in table (the SDK auto-resolves);\n3) Perform Guard verification tests after the Host Object is published;\n4) Use guard2file to export a Guard backup for restoring references during rebuild",
+          "evidence": "Circular reference: identifier=${rx1_13_identifier}, object_type=\"${scene_host_object}\" → ${scene_host_object}",
+          "stakeholders": ["provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-14",
+      "dimension": "logic_gap",
+      "trigger": "Scene-specific reentrancy: Guard pass triggers a state-changing side effect (fund distribution, vote count, Arb creation) that does NOT naturally invalidate the Guard condition. Without an anti-reentrancy primitive, the same Signer can repeatedly pass the Guard. Additionally detects pseudo-protection: primitive present but not properly wrapped in logic_not (for Bool queries) or logic_equal(0) (for count queries).",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "reentry_applicable", "op": "eq", "value": true }, { "field": "reentry_state", "op": "eq", "value": "pseudo" }, { "field": "reentry_scene_id", "op": "eq", "value": "reward_claim" }] },
+          "level": "medium",
+          "title": "Reentrancy pseudo-protection: anti-reentrancy primitive present but not properly wrapped (${reentry_scene_id})",
+          "description": "Scene: ${reentry_scene_id}\nThe Guard root contains an anti-reentrancy primitive (${reentry_found_primitive}), but it is NOT properly wrapped.\nProper wrapping rules:\n  - Bool-returning primitives (exists-style): must be wrapped in logic_not\n  - U64-returning primitives (count-style): must be compared to 0 via logic_equal\n  - Address-returning primitives: must be wrapped in logic_not (None check)\n\nWHY THIS IS DANGEROUS:\n  The developer likely intended to prevent reentrancy but the wrapping is incorrect, so the primitive does NOT actually block repeated Guard passes. This is arguably MORE dangerous than absence — code reviewers see the primitive and assume protection is in place.\n\nScene rationale: ${reentry_rationale}",
+          "scenario": "Developer added anti-reentrancy primitive but used wrong wrapping; reentrancy exploit still possible in ${reentry_scene_id}",
+          "mitigation": "Fix the wrapping:\n  - For exists-style (Bool) primitives: wrap in logic_not — { type: 'logic_not', node: { type: 'query', query: <primitive>, ... } }\n  - For count-style (U64) primitives: compare to 0 — { type: 'logic_equal', nodes: [ { type: 'query', query: <primitive>, ... }, identifier(N) ] } where table[N].value = 0\n  - For address-style primitives: wrap in logic_not (None check)\nThen wrap the protection in logic_and with the existing root conditions.\n\nFull mitigation for ${reentry_scene_id}:\n${reentry_mitigation}",
+          "evidence": "${reentry_evidence}",
+          "stakeholders": ["claimant", "provider"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "The reward pool is the merchant's deposited budget — repeated Guard passes let the same signer drain it multiple times." }
+            ],
+            "gain_paths": [
+              {
+                "role": "neutral",
+                "path": "The same signer repeatedly passes the claim Guard and collects the payout again each time.",
+                "viability": "viable",
+                "gate": "The anti-reentrancy primitive is absent or mis-wrapped, so no on-chain check blocks the repeat pass."
+              }
+            ]
+          }
+        },
+        {
+          "when": { "all": [{ "field": "reentry_applicable", "op": "eq", "value": true }, { "field": "reentry_state", "op": "eq", "value": "pseudo" }, { "field": "reentry_scene_id", "op": "eq", "value": "arbitration_voting_guard" }] },
+          "level": "medium",
+          "title": "Reentrancy pseudo-protection: anti-reentrancy primitive present but not properly wrapped (${reentry_scene_id})",
+          "description": "Scene: ${reentry_scene_id}\nThe Guard root contains an anti-reentrancy primitive (${reentry_found_primitive}), but it is NOT properly wrapped.\nProper wrapping rules:\n  - Bool-returning primitives (exists-style): must be wrapped in logic_not\n  - U64-returning primitives (count-style): must be compared to 0 via logic_equal\n  - Address-returning primitives: must be wrapped in logic_not (None check)\n\nWHY THIS IS DANGEROUS:\n  The developer likely intended to prevent reentrancy but the wrapping is incorrect, so the primitive does NOT actually block repeated Guard passes. This is arguably MORE dangerous than absence — code reviewers see the primitive and assume protection is in place.\n\nScene rationale: ${reentry_rationale}",
+          "scenario": "Developer added anti-reentrancy primitive but used wrong wrapping; reentrancy exploit still possible in ${reentry_scene_id}",
+          "mitigation": "Fix the wrapping:\n  - For exists-style (Bool) primitives: wrap in logic_not — { type: 'logic_not', node: { type: 'query', query: <primitive>, ... } }\n  - For count-style (U64) primitives: compare to 0 — { type: 'logic_equal', nodes: [ { type: 'query', query: <primitive>, ... }, identifier(N) ] } where table[N].value = 0\n  - For address-style primitives: wrap in logic_not (None check)\nThen wrap the protection in logic_and with the existing root conditions.\n\nFull mitigation for ${reentry_scene_id}:\n${reentry_mitigation}",
+          "evidence": "${reentry_evidence}",
+          "stakeholders": ["customer", "provider", "arbitrator"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "Repeated vote counting can swing the arbitration ruling — the buyer may be denied a deserved payout or charged a wrongful one." },
+              { "role": "merchant", "basis": "The same manipulated ruling can force an unjustified compensation payout from the merchant side." }
+            ],
+            "gain_paths": [
+              {
+                "role": "neutral",
+                "path": "The same signer repeatedly passes the voting Guard, re-triggering the vote-count side effect until the tally favors them.",
+                "viability": "viable",
+                "gate": "The anti-reentrancy primitive is absent or mis-wrapped, so no on-chain check blocks the repeat pass."
+              }
+            ]
+          }
+        },
+        {
+          "when": { "all": [{ "field": "reentry_applicable", "op": "eq", "value": true }, { "field": "reentry_state", "op": "eq", "value": "pseudo" }, { "field": "reentry_scene_id", "op": "eq", "value": "arbitration_usage_guard" }] },
+          "level": "medium",
+          "title": "Reentrancy pseudo-protection: anti-reentrancy primitive present but not properly wrapped (${reentry_scene_id})",
+          "description": "Scene: ${reentry_scene_id}\nThe Guard root contains an anti-reentrancy primitive (${reentry_found_primitive}), but it is NOT properly wrapped.\nProper wrapping rules:\n  - Bool-returning primitives (exists-style): must be wrapped in logic_not\n  - U64-returning primitives (count-style): must be compared to 0 via logic_equal\n  - Address-returning primitives: must be wrapped in logic_not (None check)\n\nWHY THIS IS DANGEROUS:\n  The developer likely intended to prevent reentrancy but the wrapping is incorrect, so the primitive does NOT actually block repeated Guard passes. This is arguably MORE dangerous than absence — code reviewers see the primitive and assume protection is in place.\n\nScene rationale: ${reentry_rationale}",
+          "scenario": "Developer added anti-reentrancy primitive but used wrong wrapping; reentrancy exploit still possible in ${reentry_scene_id}",
+          "mitigation": "Fix the wrapping:\n  - For exists-style (Bool) primitives: wrap in logic_not — { type: 'logic_not', node: { type: 'query', query: <primitive>, ... } }\n  - For count-style (U64) primitives: compare to 0 — { type: 'logic_equal', nodes: [ { type: 'query', query: <primitive>, ... }, identifier(N) ] } where table[N].value = 0\n  - For address-style primitives: wrap in logic_not (None check)\nThen wrap the protection in logic_and with the existing root conditions.\n\nFull mitigation for ${reentry_scene_id}:\n${reentry_mitigation}",
+          "evidence": "${reentry_evidence}",
+          "stakeholders": ["customer", "provider"]
+        },
+        {
+          "when": { "all": [{ "field": "reentry_applicable", "op": "eq", "value": true }, { "field": "reentry_state", "op": "eq", "value": "pseudo" }, { "field": "reentry_scene_id", "op": "eq", "value": "service_order_allocators_guard" }] },
+          "level": "medium",
+          "title": "Reentrancy pseudo-protection: anti-reentrancy primitive present but not properly wrapped (${reentry_scene_id})",
+          "description": "Scene: ${reentry_scene_id}\nThe Guard root contains an anti-reentrancy primitive (${reentry_found_primitive}), but it is NOT properly wrapped.\nProper wrapping rules:\n  - Bool-returning primitives (exists-style): must be wrapped in logic_not\n  - U64-returning primitives (count-style): must be compared to 0 via logic_equal\n  - Address-returning primitives: must be wrapped in logic_not (None check)\n\nWHY THIS IS DANGEROUS:\n  The developer likely intended to prevent reentrancy but the wrapping is incorrect, so the primitive does NOT actually block repeated Guard passes. This is arguably MORE dangerous than absence — code reviewers see the primitive and assume protection is in place.\n\nScene rationale: ${reentry_rationale}",
+          "scenario": "Developer added anti-reentrancy primitive but used wrong wrapping; reentrancy exploit still possible in ${reentry_scene_id}",
+          "mitigation": "Fix the wrapping:\n  - For exists-style (Bool) primitives: wrap in logic_not — { type: 'logic_not', node: { type: 'query', query: <primitive>, ... } }\n  - For count-style (U64) primitives: compare to 0 — { type: 'logic_equal', nodes: [ { type: 'query', query: <primitive>, ... }, identifier(N) ] } where table[N].value = 0\n  - For address-style primitives: wrap in logic_not (None check)\nThen wrap the protection in logic_and with the existing root conditions.\n\nFull mitigation for ${reentry_scene_id}:\n${reentry_mitigation}",
+          "evidence": "${reentry_evidence}",
+          "stakeholders": ["customer", "provider"]
+        },
+        {
+          "when": { "all": [{ "field": "reentry_applicable", "op": "eq", "value": true }, { "field": "reentry_state", "op": "eq", "value": "pseudo" }, { "field": "reentry_scene_id", "op": "eq", "value": "service_buy_guard" }] },
+          "level": "medium",
+          "title": "Reentrancy pseudo-protection: anti-reentrancy primitive present but not properly wrapped (${reentry_scene_id})",
+          "description": "Scene: ${reentry_scene_id}\nThe Guard root contains an anti-reentrancy primitive (${reentry_found_primitive}), but it is NOT properly wrapped.\nProper wrapping rules:\n  - Bool-returning primitives (exists-style): must be wrapped in logic_not\n  - U64-returning primitives (count-style): must be compared to 0 via logic_equal\n  - Address-returning primitives: must be wrapped in logic_not (None check)\n\nWHY THIS IS DANGEROUS:\n  The developer likely intended to prevent reentrancy but the wrapping is incorrect, so the primitive does NOT actually block repeated Guard passes. This is arguably MORE dangerous than absence — code reviewers see the primitive and assume protection is in place.\n\nScene rationale: ${reentry_rationale}",
+          "scenario": "Developer added anti-reentrancy primitive but used wrong wrapping; reentrancy exploit still possible in ${reentry_scene_id}",
+          "mitigation": "Fix the wrapping:\n  - For exists-style (Bool) primitives: wrap in logic_not — { type: 'logic_not', node: { type: 'query', query: <primitive>, ... } }\n  - For count-style (U64) primitives: compare to 0 — { type: 'logic_equal', nodes: [ { type: 'query', query: <primitive>, ... }, identifier(N) ] } where table[N].value = 0\n  - For address-style primitives: wrap in logic_not (None check)\nThen wrap the protection in logic_and with the existing root conditions.\n\nFull mitigation for ${reentry_scene_id}:\n${reentry_mitigation}",
+          "evidence": "${reentry_evidence}",
+          "stakeholders": ["provider"]
+        },
+        {
+          "when": { "all": [{ "field": "reentry_applicable", "op": "eq", "value": true }, { "field": "reentry_state", "op": "eq", "value": "pseudo" }, { "field": "reentry_scene_id", "op": "eq", "value": "repository_write_guard" }] },
+          "level": "medium",
+          "title": "Reentrancy pseudo-protection: anti-reentrancy primitive present but not properly wrapped (${reentry_scene_id})",
+          "description": "Scene: ${reentry_scene_id}\nThe Guard root contains an anti-reentrancy primitive (${reentry_found_primitive}), but it is NOT properly wrapped.\nProper wrapping rules:\n  - Bool-returning primitives (exists-style): must be wrapped in logic_not\n  - U64-returning primitives (count-style): must be compared to 0 via logic_equal\n  - Address-returning primitives: must be wrapped in logic_not (None check)\n\nWHY THIS IS DANGEROUS:\n  The developer likely intended to prevent reentrancy but the wrapping is incorrect, so the primitive does NOT actually block repeated Guard passes. This is arguably MORE dangerous than absence — code reviewers see the primitive and assume protection is in place.\n\nScene rationale: ${reentry_rationale}",
+          "scenario": "Developer added anti-reentrancy primitive but used wrong wrapping; reentrancy exploit still possible in ${reentry_scene_id}",
+          "mitigation": "Fix the wrapping:\n  - For exists-style (Bool) primitives: wrap in logic_not — { type: 'logic_not', node: { type: 'query', query: <primitive>, ... } }\n  - For count-style (U64) primitives: compare to 0 — { type: 'logic_equal', nodes: [ { type: 'query', query: <primitive>, ... }, identifier(N) ] } where table[N].value = 0\n  - For address-style primitives: wrap in logic_not (None check)\nThen wrap the protection in logic_and with the existing root conditions.\n\nFull mitigation for ${reentry_scene_id}:\n${reentry_mitigation}",
+          "evidence": "${reentry_evidence}",
+          "stakeholders": ["provider"]
+        },
+        {
+          "when": { "all": [{ "field": "reentry_applicable", "op": "eq", "value": true }, { "field": "reentry_state", "op": "eq", "value": "pseudo" }, { "field": "reentry_scene_id", "op": "eq", "value": "gen_passport_guard" }] },
+          "level": "medium",
+          "title": "Reentrancy pseudo-protection: anti-reentrancy primitive present but not properly wrapped (${reentry_scene_id})",
+          "description": "Scene: ${reentry_scene_id}\nThe Guard root contains an anti-reentrancy primitive (${reentry_found_primitive}), but it is NOT properly wrapped.\nProper wrapping rules:\n  - Bool-returning primitives (exists-style): must be wrapped in logic_not\n  - U64-returning primitives (count-style): must be compared to 0 via logic_equal\n  - Address-returning primitives: must be wrapped in logic_not (None check)\n\nWHY THIS IS DANGEROUS:\n  The developer likely intended to prevent reentrancy but the wrapping is incorrect, so the primitive does NOT actually block repeated Guard passes. This is arguably MORE dangerous than absence — code reviewers see the primitive and assume protection is in place.\n\nScene rationale: ${reentry_rationale}",
+          "scenario": "Developer added anti-reentrancy primitive but used wrong wrapping; reentrancy exploit still possible in ${reentry_scene_id}",
+          "mitigation": "Fix the wrapping:\n  - For exists-style (Bool) primitives: wrap in logic_not — { type: 'logic_not', node: { type: 'query', query: <primitive>, ... } }\n  - For count-style (U64) primitives: compare to 0 — { type: 'logic_equal', nodes: [ { type: 'query', query: <primitive>, ... }, identifier(N) ] } where table[N].value = 0\n  - For address-style primitives: wrap in logic_not (None check)\nThen wrap the protection in logic_and with the existing root conditions.\n\nFull mitigation for ${reentry_scene_id}:\n${reentry_mitigation}",
+          "evidence": "${reentry_evidence}",
+          "stakeholders": ["provider"]
+        },
+        {
+          "when": { "all": [{ "field": "reentry_applicable", "op": "eq", "value": true }, { "field": "reentry_state", "op": "eq", "value": "absent" }, { "field": "reentry_scene_id", "op": "eq", "value": "reward_claim" }] },
+          "level": "critical",
+          "title": "Reentrancy risk: ${reentry_scene_id} has NO anti-reentrancy protection (CRITICAL)",
+          "description": "Scene: ${reentry_scene_id}\nReentrancy risk level: CRITICAL\n\nRATIONALE:\n${reentry_rationale}\n\nDETECTION:\n${reentry_evidence}\n\nIMPACT: Without protection, the same Signer can repeatedly trigger the side effect (fund distribution / vote counting), causing direct fund loss or result manipulation. THIS IS A CRITICAL VULNERABILITY — the Guard MUST be rebuilt with an anti-reentrancy primitive before deployment.\n\n",
+          "scenario": "${reentry_scene_id} lacks anti-reentrancy primitive; same Signer can repeatedly trigger the side effect",
+          "mitigation": "${reentry_mitigation}",
+          "evidence": "${reentry_evidence}",
+          "stakeholders": ["claimant", "provider"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "The reward pool is the merchant's deposited budget — repeated Guard passes let the same signer drain it multiple times." }
+            ],
+            "gain_paths": [
+              {
+                "role": "neutral",
+                "path": "The same signer repeatedly passes the claim Guard and collects the payout again each time.",
+                "viability": "viable",
+                "gate": "The anti-reentrancy primitive is absent or mis-wrapped, so no on-chain check blocks the repeat pass."
+              }
+            ]
+          }
+        },
+        {
+          "when": { "all": [{ "field": "reentry_applicable", "op": "eq", "value": true }, { "field": "reentry_state", "op": "eq", "value": "absent" }, { "field": "reentry_scene_id", "op": "eq", "value": "arbitration_voting_guard" }] },
+          "level": "critical",
+          "title": "Reentrancy risk: ${reentry_scene_id} has NO anti-reentrancy protection (CRITICAL)",
+          "description": "Scene: ${reentry_scene_id}\nReentrancy risk level: CRITICAL\n\nRATIONALE:\n${reentry_rationale}\n\nDETECTION:\n${reentry_evidence}\n\nIMPACT: Without protection, the same Signer can repeatedly trigger the side effect (fund distribution / vote counting), causing direct fund loss or result manipulation. THIS IS A CRITICAL VULNERABILITY — the Guard MUST be rebuilt with an anti-reentrancy primitive before deployment.\n\n",
+          "scenario": "${reentry_scene_id} lacks anti-reentrancy primitive; same Signer can repeatedly trigger the side effect",
+          "mitigation": "${reentry_mitigation}",
+          "evidence": "${reentry_evidence}",
+          "stakeholders": ["customer", "provider", "arbitrator"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "Repeated vote counting can swing the arbitration ruling — the buyer may be denied a deserved payout or charged a wrongful one." },
+              { "role": "merchant", "basis": "The same manipulated ruling can force an unjustified compensation payout from the merchant side." }
+            ],
+            "gain_paths": [
+              {
+                "role": "neutral",
+                "path": "The same signer repeatedly passes the voting Guard, re-triggering the vote-count side effect until the tally favors them.",
+                "viability": "viable",
+                "gate": "The anti-reentrancy primitive is absent or mis-wrapped, so no on-chain check blocks the repeat pass."
+              }
+            ]
+          }
+        },
+        {
+          "when": { "all": [{ "field": "reentry_applicable", "op": "eq", "value": true }, { "field": "reentry_state", "op": "eq", "value": "absent" }, { "field": "reentry_scene_id", "op": "eq", "value": "arbitration_usage_guard" }] },
+          "level": "high",
+          "title": "Reentrancy risk: ${reentry_scene_id} has NO anti-reentrancy protection (HIGH)",
+          "description": "Scene: ${reentry_scene_id}\nReentrancy risk level: HIGH\n\nRATIONALE:\n${reentry_rationale}\n\nDETECTION:\n${reentry_evidence}\n\nIMPACT: Without protection, the system can be abused (multiple dispute cases, arbitration harassment). Strongly recommended to add protection.\n\n",
+          "scenario": "${reentry_scene_id} lacks anti-reentrancy primitive; same Signer can repeatedly trigger the side effect",
+          "mitigation": "${reentry_mitigation}",
+          "evidence": "${reentry_evidence}",
+          "stakeholders": ["customer", "provider"]
+        },
+        {
+          "when": { "all": [{ "field": "reentry_applicable", "op": "eq", "value": true }, { "field": "reentry_state", "op": "eq", "value": "absent" }, { "field": "reentry_scene_id", "op": "eq", "value": "service_order_allocators_guard" }] },
+          "level": "low",
+          "title": "Reentrancy reminder: ${reentry_scene_id} has no anti-reentrancy primitive (LOW risk)",
+          "description": "Scene: ${reentry_scene_id}\nReentrancy risk level: LOW\n\nRATIONALE:\n${reentry_rationale}\n\nDETECTION:\n${reentry_evidence}\n\nIMPACT: Low by default; only relevant if business intent requires single-action enforcement. Review the rationale above.\n\n",
+          "scenario": "${reentry_scene_id} lacks anti-reentrancy primitive; may or may not be needed depending on business intent",
+          "mitigation": "${reentry_mitigation}",
+          "evidence": "${reentry_evidence}",
+          "stakeholders": ["customer", "provider"]
+        },
+        {
+          "when": { "all": [{ "field": "reentry_applicable", "op": "eq", "value": true }, { "field": "reentry_state", "op": "eq", "value": "absent" }, { "field": "reentry_scene_id", "op": "eq", "value": "service_buy_guard" }] },
+          "level": "low",
+          "title": "Reentrancy reminder: ${reentry_scene_id} has no anti-reentrancy primitive (LOW risk)",
+          "description": "Scene: ${reentry_scene_id}\nReentrancy risk level: LOW\n\nRATIONALE:\n${reentry_rationale}\n\nDETECTION:\n${reentry_evidence}\n\nIMPACT: Low by default; only relevant if business intent requires single-action enforcement. Review the rationale above.\n\n",
+          "scenario": "${reentry_scene_id} lacks anti-reentrancy primitive; may or may not be needed depending on business intent",
+          "mitigation": "${reentry_mitigation}",
+          "evidence": "${reentry_evidence}",
+          "stakeholders": ["provider"]
+        },
+        {
+          "when": { "all": [{ "field": "reentry_applicable", "op": "eq", "value": true }, { "field": "reentry_state", "op": "eq", "value": "absent" }, { "field": "reentry_scene_id", "op": "eq", "value": "repository_write_guard" }] },
+          "level": "low",
+          "title": "Reentrancy reminder: ${reentry_scene_id} has no anti-reentrancy primitive (LOW risk)",
+          "description": "Scene: ${reentry_scene_id}\nReentrancy risk level: LOW\n\nRATIONALE:\n${reentry_rationale}\n\nDETECTION:\n${reentry_evidence}\n\nIMPACT: Low by default; only relevant if business intent requires single-action enforcement. Review the rationale above.\n\n",
+          "scenario": "${reentry_scene_id} lacks anti-reentrancy primitive; may or may not be needed depending on business intent",
+          "mitigation": "${reentry_mitigation}",
+          "evidence": "${reentry_evidence}",
+          "stakeholders": ["provider"]
+        },
+        {
+          "when": { "all": [{ "field": "reentry_applicable", "op": "eq", "value": true }, { "field": "reentry_state", "op": "eq", "value": "absent" }, { "field": "reentry_scene_id", "op": "eq", "value": "gen_passport_guard" }] },
+          "level": "low",
+          "title": "Reentrancy reminder: ${reentry_scene_id} has no anti-reentrancy primitive (LOW risk)",
+          "description": "Scene: ${reentry_scene_id}\nReentrancy risk level: LOW\n\nRATIONALE:\n${reentry_rationale}\n\nDETECTION:\n${reentry_evidence}\n\nIMPACT: Low by default; only relevant if business intent requires single-action enforcement. Review the rationale above.\n\n",
+          "scenario": "${reentry_scene_id} lacks anti-reentrancy primitive; may or may not be needed depending on business intent",
+          "mitigation": "${reentry_mitigation}",
+          "evidence": "${reentry_evidence}",
+          "stakeholders": ["provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-15",
+      "dimension": "logic_gap",
+      "trigger": "Guard root contains a progress.current query (id=1253 or name='progress.current'); if bound to a forward of the SAME Progress object, the guard evaluates before state transition",
+      "cases": [
+        {
+          "when": { "field": "root_has_progress_current_query", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Guard queries progress.current — verify it is NOT the same Progress object the hosting operation mutates",
+          "description": "Cognitive Principle P1: Guard validation ALWAYS occurs BEFORE the operation. This Guard contains a progress.current query. If this Guard is bound to a forward of the SAME Progress object it queries, the Guard will see the PRE-transition value (source node, not target node) and may always fail. Querying a DIFFERENT Progress object (e.g. another Machine's progress) is a valid and reasonable design pattern — the principle does not apply in that case. Allocator-bound guards are also unaffected because allocation.alloc() runs AFTER the state transition completes.",
+          "scenario": "Forward guard checks progress.current == target_node of the same Progress — always fails because the guard runs before the state transition sets the new current node",
+          "mitigation": "1) If this Guard queries the SAME Progress object the forward operates on: remove the guard from the forward, bind it ONLY to the Allocator (which runs after transition); OR change the check to verify the SOURCE node instead of the target node. 2) If this Guard queries a DIFFERENT Progress object (cross-machine): no action needed — this is a legitimate pattern. 3) The full principle and code evidence are stated in the description above (Cognitive Principle P1).",
+          "evidence": "Root contains progress.current query (id=1253). Query IDs detected: [${root_query_ids_csv}].",
+          "stakeholders": ["provider"]
+        }
+      ]
+    }
+  ]
+}