@wowok/agent-mcp 3.4.3 → 3.4.4

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

@@ -0,0 +1,1192 @@
+{
+  "comment": "Guard rule pack (R-C/R-X) — declarative form of the retired in-code Guard risk rules (the guard condition-tree lint pack: 39 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, the certain-outcome folder 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).",
+    "queries_arb_status": "KERNEL — the serialized root mentions arb.status (Arb case state query).",
+    "arb_status_transient_gate": "KERNEL — the root queries arb.status AND the table pins a constant numeric value of 5 (Finished): a transient-state gate that arb_withdraw (5→6 Withdrawn) will permanently overtake (testnet o10 refund-edge deadlock).",
+    "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 names a DIFFERENT system object (0xaab annotated as linker/permission/contact/messenger, or 0xaaa annotated as entity/permission/contact/messenger). Note: 0xaab is the Move-level Entity object (SDK constant ENTITY_REGISTRAR_ADDRESS — legacy alias) and 0xaaa is the Registrar object (SDK constant ENTITY_LINKER_ADDRESS — legacy alias); alias-vs-Move-name divergence is documented, not flagged (rex5 T-06).",
+    "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.",
+    "rc2_05_mismatch_count": "KERNEL — query prefixes that contradict their convert_witness target type (the witness matrix is directional; zrmn-261012 R-WITNESS-01).",
+    "rc2_05_evidence_lines": "KERNEL — the prefix-mismatch list rendered as '  - <detail>' lines, newline joined.",
+    "rc2_06_issue_count": "KERNEL — progress.* queries on a source without convert_witness that cannot be proven to be a Progress (no PROGRESS→ORDER reverse edge).",
+    "rc2_06_has_hard_mismatch": "KERNEL — at least one such source is explicitly annotated as a non-Progress (hard violation; unannotated sources grade soft).",
+    "rc2_06_evidence_lines": "KERNEL — the reverse-edge issue list rendered as '  - <detail>' lines, newline joined.",
+    "rc2_07_keys_where_count": "KERNEL — number of 'keys where' query nodes whose parameter shape DIVERGES from the native signature (nnd3-mn-261103 F-NND-04: the native 1177 signature IS (Address, VectorU8), wobject.rs:773-780 — the parameter-carrying form works on chain, mainnet-verified tx CdNmNcTf…; only arity/type mismatches abort with GUARD_QUERY_PARAM_INVALID).",
+    "rc2_07_evidence_lines": "KERNEL — per-node evidence lines for the divergent keys-where shapes counted by rc2_07_keys_where_count (query id, param arity/type vs the native signature, materialization failure mode).",
+    "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_01_order_anchored": "KERNEL — allocators scene where EVERY submission slot is unread by the root: submitted values cannot influence the verdict, and the chain binds GuardIdentifier recipients to the paying order via payment_info.for_object (ptrn-mn-261013 F-03).",
+    "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. Since protocol v148 (assert_task_binding live) the set is machine_forward_guard only: the forward-stage replay past acceptance gates is not closed by the chain, while allocator scenes carry the v148 chain backstop and grade info.",
+    "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_01_identity_legal": "KERNEL — the root carries a LEGAL identity form (order.owner equality / order.agent leg / order.service binding / permission.(owner|admin) role) => the blanket 'direction needs manual confirmation' WARN is silenced (K3 C4 bkg F-04).",
+    "rc4_01_identity_form": "KERNEL — the detected identity form label: 'order.owner ==', 'order.agent leg', 'order.service binding', 'permission role', or 'unrecognized'.",
+    "rc4_01_settlement_buyer_trigger": "KERNEL — a BUYER-form leg (order.owner equality / order.agent) on a NON-refund order_allocators rail => the role-reversal WARN stays: the buyer's signature would release the merchant's money. Refund rails are exempt (user slot 0 = submitted Order).",
+    "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 an EMPTY name (no data contract on any layer). Short identifier-style names are schema-conformant and NOT flagged (docs#46-1).",
+    "rx1_12_vague_csv": "KERNEL — unnamed 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.",
+    "rx1_19_order_query_count": "KERNEL — order.* query occurrences in a buy-scene guard root (the Order does not exist at buy time, zrmn-261012 R-BUY-GUARD-CIRCULAR).",
+    "rx1_19_evidence_csv": "KERNEL — the matched order.* query JSON fragments, comma-space joined.",
+    "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).",
+    "tree_folds_always_true": "KERNEL — the condition tree provably evaluates to TRUE for every submission and every on-chain state (certain-outcome folder in guard-risk.ts: constant-true table leaf, reflexive comparison of the same operand, unsigned value compared >= the constant 0, or an and/or/logic_not fold of such).",
+    "tree_folds_always_true_reason": "KERNEL — the decisive tautology pattern rendered for the evidence line.",
+    "tree_folds_always_false": "KERNEL — the condition tree provably evaluates to FALSE (always denies: legitimate dead-edge / frozen-service pattern, reported as a notice, not as open access).",
+    "tree_folds_always_false_reason": "KERNEL — the decisive always-false pattern rendered for the evidence line.",
+    "write_guard_scene": "KERNEL — the Guard is bound as a Repository policy write_guard (scene binding_field=write_guard / id repository_write_guard).",
+    "write_guard_no_identity_check": "KERNEL — write_guard scene AND no context(Signer) leaf anywhere in the root: the gate binds a STATE, never the WRITER, so any caller satisfying it may write or overwrite any row.",
+    "write_guard_open": "KERNEL — write_guard scene AND (the tree folds true OR it binds no caller identity): the Repository write is effectively unauthenticated even though the policy has a guard.",
+    "bare_bool_query_count": "KERNEL — number of DISTINCT query nodes sitting directly under logic_and/logic_or (bare Bool clause position; absent when zero).",
+    "bare_bool_query_csv_sp": "KERNEL — those bare-clause queries rendered '#<id>' or by name, comma-space joined."
+  },
+  "rules": [
+    {
+      "rule_id": "R-X1-16",
+      "dimension": "data_source_trust",
+      "trigger": "Guard queries arb.status and pins a constant numeric table entry to 5 (Finished) — a transient state that arb_withdraw overtakes (5→6 Withdrawn)",
+      "cases": [
+        {
+          "when": { "field": "arb_status_transient_gate", "op": "eq", "value": true },
+          "level": "high",
+          "title": "arb.status==5 gate is transient: fee withdrawal permanently kills the refund edge",
+          "description": "arb.status is a U8 lifecycle state. After a ruling the case sits at 5 (Finished), but a legitimate arb_withdraw by the arbitrator advances it to 6 (Withdrawn) — the gate silently flips false and never returns. Guard AND Machine are immutable after publish (IMMUT-001), so any forward gated on ==5 dies permanently and strands its funds (verified on testnet, booking o10: 1.5 WOW locked with no on-chain exit).",
+          "scenario": "Arbitration refund forward gated on arb.status==5: the arbitrator withdraws the case fee before the refund executes — the forward aborts forever",
+          "mitigation": "Gate on the stable ruling signal instead: arb.indemnity some == true (Bool — set by the ruling; arb_withdraw sweeps only the fee balance and never touches it, so a fee withdrawal cannot clear it; cleared by reset, which correctly re-gates). Template: tpl_forward_arb_ruling_won. Time-bounded variant: arb.indemnity.time (U64 ruling timestamp). Merchant-favor dismissal edges: tpl_forward_arb_ruling_dismissed (arb.indemnity.amount == 0 — fail-closed on the None field).",
+          "evidence": "Root queries arb.status; table pins a constant numeric value of 5 (Finished).",
+          "stakeholders": ["provider", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-17",
+      "dimension": "logic_gap",
+      "trigger": "The condition tree folds to TRUE for every input (tautology), or a Repository write_guard binds no caller identity — the chain checks that a write_guard EXISTS, never that it PROVES anything",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "write_guard_scene", "op": "eq", "value": true }, { "field": "tree_folds_always_true", "op": "eq", "value": true }] },
+          "level": "critical",
+          "title": "Repository write_guard is a tautology — evidence writes are open to every address",
+          "description": "policy_add_imp asserts only that the write_guard LIST IS NON-EMPTY when a policy's id_from is NONE (repository.move L511-536, E_POLICY_WRITE_GUARD_REQUIRED = 22); nothing on chain evaluates what the Guard authorizes. A Guard that returns true for every caller is therefore accepted silently and is exactly the open door an empty list would have been — the schema warning for 'write_guard missing' does not fire, so the misconfiguration is invisible until exploited. Verified on testnet (test-14, HIGH-04): a NON-merchant signer wrote a forged tracking row for another buyer's order (tx BLA7F62r…), then the merchant's legitimate write simply upserted over it (tx DaZaPn6o…). Every downstream Guard that gates a forward on repository.data EXISTENCE (repository.data has / count where) is satisfied by the forged row, so shipping/return evidence stops being evidence; Repository rows carry no author field, so a signed WTS Proof (proof.signer / proof.about / proof.time) is the only on-chain provenance.",
+          "scenario": "Merchant binds a 'true' placeholder as the evidence Repository write_guard to satisfy the schema; a stranger (or the counterparty in a dispute) pre-writes the shipping/return receipt row and the delivery forward's evidence gate passes on forged data",
+          "mitigation": "Delete the placeholder: bind the writer. Minimum = context(Signer) equality against a constant Address or a vec_contains_address allowlist entry; better = the merchant Permission entity (permission index) or the Order holder via witness, so the row is attributable to the party that owns the order. For evidence that must survive a dispute, store a signed WTS Proof (Prover+Time+Content, repository.move L160-171) instead of a bare string. If genuinely open writes are intended, use id_from=Signer/Clock instead of a write_guard — that is the protocol's declared way to allow anyone.",
+          "evidence": "Tautology: ${tree_folds_always_true_reason}",
+          "stakeholders": ["customer", "provider", "arbitrator"]
+        },
+        {
+          "when": { "all": [{ "field": "write_guard_scene", "op": "eq", "value": true }, { "field": "tree_folds_always_true", "op": "eq", "value": false }, { "field": "write_guard_no_identity_check", "op": "eq", "value": true }] },
+          "level": "high",
+          "title": "Repository write_guard gates a state, not a writer — any qualifying caller may overwrite any row",
+          "description": "The policy has a write_guard, but the tree contains no context(Signer) leaf, so it never asks WHO is writing. The gate can be satisfied by anyone who can present the referenced objects (or who simply owns them), and once satisfied the writer may add OR OVERWRITE any data ID under that policy — Repository rows carry no author. Downstream Guards that check existence (repository.data has) then trust data with no provenance.",
+          "scenario": "Ship-evidence policy guarded only by 'the submitted Order exists': the buyer writes the seller-side shipping receipt themselves, and the deliver forward's evidence check passes",
+          "mitigation": "Add the identity leaf: context(Signer) == a constant merchant Address, or vec_contains_address against an allowlist / permission entity table, or the Order holder derived by witness. Where the row must be provably authored, write a signed WTS Proof rather than a bare value, and have the consuming Guard check proof.attestation == the expected party instead of mere existence.",
+          "evidence": "write_guard scene with no context(Signer) leaf in the root",
+          "stakeholders": ["customer", "provider", "arbitrator"]
+        },
+        {
+          "when": { "all": [{ "field": "scene_id", "op": "eq", "value": "arbitration_voting_guard" }, { "field": "tree_folds_always_true", "op": "eq", "value": true }] },
+          "level": "low",
+          "title": "Open-vote tautology on voting_guard — the declared voter universe, not a placeholder",
+          "description": "On the Arbitration voting slot an always-true guard is the SANCTIONED open-voting form: every Passport holder passes and votes at the row's FixedValue weight (tpl_voting_guard_open_vote). It matches the tautology signature R-X1-17 hunts, but here the alternative is the real hazard: an EMPTY voting_guard does not mean 'everyone may vote' — plain votes hard-require the vote permission (358), admin-only by default, and a dispute dead-locks when that admin is unresponsive (R-ARB-VOTE-LOCK blocks the service publish; crs9-F-36, mainnet-verified 2026-10-15).",
+          "scenario": "A merchant designs a public arbitration venue and binds the always-true voting guard; the tautology check must not scare them into leaving voting_guard empty",
+          "mitigation": "None needed — this is the declared intent. Confirm the weight row is FixedValue (flat one-voter-one-vote) or an intentional tier, and remember every vote call must carry the voting_guard payload once the field is set (a plain vote aborts with E_VOTING_GUARD_USED, abort 2). Weighted panels should use tpl_voting_guard_numeric_weight instead.",
+          "evidence": "Tautology: ${tree_folds_always_true_reason} (voting_guard scene — open-vote semantics)",
+          "stakeholders": ["customer", "provider", "arbitrator"]
+        },
+        {
+          "when": { "all": [{ "field": "tree_folds_always_true", "op": "eq", "value": true }, { "field": "write_guard_scene", "op": "eq", "value": false }] },
+          "level": "high",
+          "title": "Guard is a tautology — whatever it gates is unrestricted",
+          "description": "The condition tree evaluates to true for every submission and every on-chain state, so binding it to a Forward / buy / allocator / usage slot authorizes every caller while LOOKING guarded. Guards are immutable once published (IMMUT-001): the binding cannot be repaired in place, only by standing up new objects and rebinding what is still mutable (L3 fields).",
+          "scenario": "A placeholder guard (constant-true entry, self-comparison, x >= 0) shipped as 'to be filled in later' gets bound to a forward; the workflow accepts any caller from day one and can never be tightened after publish",
+          "mitigation": "Before publishing the host object, replace the placeholder with a real predicate; if the intent is genuinely 'no gate', leave the binding EMPTY instead of binding an always-true Guard (an empty binding is honest; a tautology is a false assurance). Re-check with the Guard analyzer after every edit.",
+          "evidence": "Tautology: ${tree_folds_always_true_reason}",
+          "stakeholders": ["customer", "provider"]
+        },
+        {
+          "when": { "field": "tree_folds_always_false", "op": "eq", "value": true },
+          "level": "low",
+          "title": "Guard is always false — nothing it gates can ever run",
+          "description": "The tree folds to false for every input (the certain-outcome folder found a decisive always-false expression). This is the safe direction of error — it denies rather than opens — and is sometimes intentional (a deliberately frozen edge), but it is far more often a polarity or identifier mistake, and after publish the gated path is dead permanently (IMMUT-001).",
+          "scenario": "Merchant wants 'not yet shipped' and writes logic_equal[current_node, shipped_constant] inside a forward that only runs AFTER shipping; the forward can never fire",
+          "mitigation": "Confirm the intent. If the edge must ever run, fix the predicate before publishing; if it is a permanent block, prefer NOT binding a Guard at all and instead leaving the edge unreachable in the Machine graph (clearer to readers and to the workflow analyzer).",
+          "evidence": "Always-false: ${tree_folds_always_false_reason}",
+          "stakeholders": ["provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-18",
+      "dimension": "logic_gap",
+      "trigger": "A query node sits directly under logic_and/logic_or — a bare Bool clause asserting the POSITIVE state of whatever it reads (OFN mainnet #P-01)",
+      "cases": [
+        {
+          "when": { "field": "bare_bool_query_count", "op": "present" },
+          "level": "medium",
+          "title": "Bare Bool query clause (${bare_bool_query_csv_sp}) asserts the POSITIVE state — polarity unchecked",
+          "description": "A query placed directly under logic_and/logic_or must return Bool and asserts that the condition IS true ('is set / exists / claimed'). OFN mainnet #P-01: a refund guard used a bare order.claimed_by-some query (id 1570) — it reads 'already claimed', so it is FALSE on every fresh order; all five refund rails aborted (code 7), and order_allocators is immutable after publish (service.move asserts !bPublished), so the Service had to be rebuilt from scratch. When the intent is the NEGATIVE — the common refund/double-spend guard pattern ('not yet claimed', 'no allocation yet') — a bare clause expresses the exact opposite of what the author meant.",
+          "scenario": "Refund guard with a bare claimed_by query: every refund call aborts on a fresh order, and publish freezes the misconfiguration permanently",
+          "mitigation": "Wrap the query in logic_equal with an explicit Bool constant so the polarity is stated: logic_equal[query(order.claimed_by some), Bool false] for 'not yet claimed' (the refund pattern); logic_equal[query(...), Bool true] when the positive state is genuinely required. Re-run the Guard analyzer after the edit.",
+          "evidence": "Bare query clause(s) under logic_and/logic_or: ${bare_bool_query_csv_sp}",
+          "stakeholders": ["provider", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-X1-19",
+      "dimension": "logic_gap",
+      "trigger": "A buy-scene guard queries order.* — the Order does not exist at buy time (zrmn-261012 R-BUY-GUARD-CIRCULAR)",
+      "cases": [
+        {
+          "when": { "field": "rx1_19_order_query_count", "op": "gt", "value": 0 },
+          "level": "critical",
+          "title": "Buy guard queries order.* (${rx1_19_evidence_csv}) — the Order does not exist yet, creation aborts",
+          "description": "The buy guard evaluates BEFORE the Order object exists (it gates the transaction that creates it), so every order.* query inside it is circular and cannot resolve. The ziroom mainnet run (zrmn-261012) shipped exactly this shape: a buy guard querying order.item has / order.amount — creation failed at name resolution.",
+          "scenario": "Circular buy gate: guard creation or first purchase aborts because the queried Order is the one being created",
+          "mitigation": "1) Buy-time state lives on the SERVICE, not the Order: query service.* fields (e.g. service.paused) or use table constants;\n2) Post-purchase invariants (amount, item) belong on forward/allocator guards, which run after the Order exists;\n3) ${rx1_19_evidence_csv}",
+          "evidence": "order.* queries in buy-scene guard: ${rx1_19_evidence_csv}",
+          "stakeholders": ["provider"]
+        }
+      ]
+    },
+    {
+      "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 Entity-object(0xaab) or Registrar(0xaaa) system address constants",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "sys_addr_list", "op": "present" }, { "field": "sys_addr_wrong", "op": "eq", "value": true }] },
+          "level": "medium",
+          "title": "System address name annotation suspected to be wrong",
+          "description": "Chain truth: 0xaab is the Entity object (WOW_ENTITY_OBJECT_ID — where per-address entity registration records live) and 0xaaa is the Registrar object (WOW_REGISTRAR_OBJECT_ID). The SDK exported constants use legacy aliases (ENTITY_REGISTRAR_ADDRESS=0xaab, ENTITY_LINKER_ADDRESS=0xaaa). The detected annotation names a DIFFERENT system object (e.g. 0xaab annotated as linker), which may cause the Guard to query the wrong object.",
+          "scenario": "System address misuse: an annotation naming another system object causes query-target confusion",
+          "mitigation": "1) 0xaab is the Entity object (registration records; SDK alias 'EntityRegistrar');2) 0xaaa is the Registrar object (SDK alias 'EntityLinker');3) The table entry name should indicate the intended system object 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 Entity-object/Registrar system address constants",
+          "description": "Chain truth: 0xaab is the Entity object (WOW_ENTITY_OBJECT_ID) and 0xaaa is the Registrar object (WOW_REGISTRAR_OBJECT_ID); SDK constants use legacy aliases (ENTITY_REGISTRAR_ADDRESS=0xaab, ENTITY_LINKER_ADDRESS=0xaaa). Address usage looks consistent; keep the name annotation clear to avoid later maintenance confusion.",
+          "scenario": "System address usage: alias-vs-Move-name divergence documented for maintainers",
+          "mitigation": "1) 0xaab is the Entity object (registration records; SDK alias 'EntityRegistrar');2) 0xaaa is the Registrar object (SDK alias 'EntityLinker');3) The table entry name should indicate the intended system object 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-C2-05",
+      "dimension": "data_source_trust",
+      "trigger": "Guard uses convert_witness but the query path prefix does not live on the witness target type (zrmn-261012 R-WITNESS-01: 17 mainnet guards rejected)",
+      "cases": [
+        {
+          "when": { "field": "rc2_05_mismatch_count", "op": "gt", "value": 0 },
+          "level": "critical",
+          "title": "Query path contradicts the witness target type — the chain rejects this guard",
+          "description": "convert_witness resolves the object reference to the edge's TARGET type, and the query path prefix must exist on that type. The on-chain witness matrix (common.move) is directional and has NO reverse edges.\n${rc2_05_evidence_lines}\nThis shape aborts at guard creation (native verifier type check) or silently gates on nothing — both are deterministic failures.",
+          "scenario": "Witness misuse: convert to Progress then query order.* — type mismatch rejects the guard",
+          "mitigation": "1) Make the query prefix match the witness target: 100 OrderProgress→progress.*, 101 OrderMachine→machine.*, 102 OrderService→service.*, 103 ProgressMachine→machine.*, 104 ArbOrder→order.*, 105 ArbArbitration→arb.*, 106-108 Arb→progress./service./machine.*, 109 OrderAllocation→allocation.*;\n2) If you meant to read Order fields, DROP the convert_witness (query order.* directly on the submitted Order);\n3) Run analyze_guard_semantics before creation",
+          "evidence": "${rc2_05_evidence_lines}",
+          "stakeholders": ["provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-C2-06",
+      "dimension": "data_source_trust",
+      "trigger": "Guard queries progress.* without convert_witness on an object that is not a Progress (no PROGRESS→ORDER reverse edge)",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "rc2_06_issue_count", "op": "gt", "value": 0 }, { "field": "rc2_06_has_hard_mismatch", "op": "eq", "value": true }] },
+          "level": "critical",
+          "title": "progress.* queried on a non-Progress object without conversion — unresolvable on-chain",
+          "description": "The chain has NO PROGRESS→ORDER reverse edge: the only legal way to read progress fields from an Order submission is convert_witness 100 (OrderProgress).\n${rc2_06_evidence_lines}",
+          "scenario": "Reverse-edge misuse: order submitted, progress.current queried without conversion — query returns empty or aborts",
+          "mitigation": "1) Add convert_witness 100 (or the string name 'OrderProgress') to the query's object ref;\n2) Keep the query path as progress.* after conversion;\n3) Alternatively submit the Progress object itself and annotate object_type=Progress",
+          "evidence": "${rc2_06_evidence_lines}",
+          "stakeholders": ["provider"]
+        },
+        {
+          "when": { "all": [{ "field": "rc2_06_issue_count", "op": "gt", "value": 0 }, { "field": "rc2_06_has_hard_mismatch", "op": "eq", "value": false }] },
+          "level": "high",
+          "title": "progress.* queried on an annotated submission without object_type — verify the source type",
+          "description": "A query reads progress.* from a submission without convert_witness, and the table entry lacks an object_type annotation, so the source type cannot be validated statically.\n${rc2_06_evidence_lines}\nIf the submitted value is the ORDER address, the query is unresolvable (no PROGRESS→ORDER reverse edge).",
+          "scenario": "Unverifiable source type: progress query on an unannotated submission may target the Order",
+          "mitigation": "1) Annotate the table entry's object_type (Progress/Order/Arb);\n2) If the submission is the Order, add convert_witness 100 (OrderProgress);\n3) Verify with analyze_guard_semantics before creation",
+          "evidence": "${rc2_06_evidence_lines}",
+          "stakeholders": ["provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-C2-07",
+      "dimension": "data_source_trust",
+      "trigger": "Guard uses a repository.data 'keys where' predicate whose parameter shape diverges from the native signature (nnd3-mn-261103 F-NND-04: parameter-carrying 1177 (Address, VectorU8) is the native canonical shape and works on chain — mainnet-verified)",
+      "cases": [
+        {
+          "when": { "field": "rc2_07_keys_where_count", "op": "gt", "value": 0 },
+          "level": "high",
+          "title": "keys-where query parameter shape diverges from the native signature",
+          "description": "The native 1177 'repository.data keys where' signature IS (Address, VectorU8) — wobject.rs:773-780, enforced len()==2 in repository.rs data_keys_where. The parameter-carrying canonical shape WORKS on chain (nnd3 mainnet: the 1177 prize rail paid out, tx CdNmNcTf…/GytKV75b…), and the parameter-free Range-gte shape (predicate in the BCS conditions blob) also stays valid. What aborts is a DIVERGENT shape: wrong arity or a constant whose value_type can never materialize as the required parameter type — MovePrimitiveRuntimeError GUARD_QUERY_PARAM_INVALID at verification. ${rc2_07_keys_where_count} divergent node(s) found:\n${rc2_07_evidence_lines}",
+          "scenario": "Native abort: a keys-where node with a parameter arity/type mismatch fails verification with GUARD_QUERY_PARAM_INVALID",
+          "mitigation": "1) Match the native signature exactly — 1177 wants (Address candidate id, VectorU8 BCS predicate);\n2) or drop parameters entirely and express the predicate as Range-gte inside the BCS conditions blob (batch-14 certified shape);\n3) See guard-design-patterns pattern.repository_data_check and LAYERED RATING-RANGE RULING in builtin-templates for proven shapes",
+          "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": "rc3_01_order_anchored", "op": "eq", "value": true }, { "field": "rc3_01_sharing_exempt", "op": "eq", "value": false }, { "field": "has_signer_check", "op": "eq", "value": false }] },
+          "level": "info",
+          "title": "Order-anchored recipient slots — Signer binding is structurally inapplicable",
+          "description": "Every submission slot is unread by the condition tree, so submitted values cannot influence the verdict. In the order_allocators scene the only consumption is the chain-side GuardIdentifier recipient read, which payment_info.for_object hard-binds to the paying order: order-created allocations always bind, and submitted != for_object aborts (ERECIPIENT_NOT_FOR_OBJECT). Adding a Signer binding here would BREAK keeper/service-triggered rails — a merchant-triggered refund cannot satisfy Signer==recipient. Verified live on mainnet: a merchant-triggered refund still paid the buyer (ptrn-mn-261013 F-03).",
+          "scenario": "Order-anchored payout rails (refund / recovery / settlement allocators resolved through a GuardIdentifier recipient).",
+          "mitigation": "No change needed. Residual: only standalone (non-order) Allocation runs with an unbound payment_info let the passport builder choose the recipient — that surface is the allocation owner's policy decision, not a guard defect. If a submitted slot is later READ by the condition tree, the normal R-C3-01 binding rules resume.",
+          "stakeholders": ["provider", "customer"]
+        },
+        {
+          "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": "info",
+          "title": "Submitted Order/Progress/Arb is NOT verified to belong to the current project — advisory: the chain now rejects cross-order submissions at the Progress layer (protocol v148, N-1 assert_task_binding); keep the project binding as defense-in-depth",
+          "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. Chain backstop (protocol v148): progress.move assert_task_binding requires the passport's identifier-254 submission to equal Progress.task on every guard-gated forward of a task-bound Progress — cross-order replay aborts with 11 (binding required) / 12 (binding mismatch).",
+          "stakeholders": ["customer", "provider", "arbitrator"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "Historical (pre-v148): time-lock, status and allocation conditions stopped protecting the project — funds could be released before the merchant's obligations were met. Since protocol v148 the chain rejects cross-order evidence at the Progress layer, so this loss path no longer materializes." },
+              { "role": "buyer", "basis": "Historical (pre-v148): the buyer's order protections (time-locks, status gates) could be bypassed with a foreign project's object. Since protocol v148 the task binding closes that path; the missing project queries remain a defense-in-depth gap only." }
+            ],
+            "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": "blocked",
+                "gate": "protocol v148 assert_task_binding runs on every guard-gated forward of a task-bound Progress and aborts when the identifier-254 submission does not equal Progress.task — the forged-evidence forward is rejected by the chain after guard verification, before the node can advance."
+              }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "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  - Each allocator is bound to a DIFFERENT guard — the caller's submitted guard selects which path fires. Same-guard allocators fire sequentially on the same call (waterfall); different-guard allocators are alternative paths.\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  - Each allocator is bound to a DIFFERENT guard — the caller's submitted guard selects which path fires. Same-guard allocators fire sequentially on the same call (waterfall); different-guard allocators are alternative paths.\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. K3 C4 (2026-11-08): the LEGAL caller-identity set for fund rails — order.owner==signer | order.agent has signer | order.service binding leg | permission.owner/admin role leg (the guard face of permission-index 1000/1001 rails) — is SILENT; the WARN stays only for (a) a buyer-form leg firing a NON-refund allocator rail (the settlement role-reversal disclosure) and (b) unrecognized identity forms.",
+      "cases": [
+        {
+          "when": { "all": [{ "field": "has_signer_check", "op": "eq", "value": true }, { "field": "rc4_01_settlement_buyer_trigger", "op": "eq", "value": true }] },
+          "level": "medium",
+          "title": "Buyer-triggered settlement (role-reversal disclosure): identity form ${rc4_01_identity_form}",
+          "description": "This allocator rail's ONLY caller face is the order-holder identity (${rc4_01_identity_form}) — the BUYER's signature is what releases the rail's money. On a NON-refund allocator rail that is the disclosed role reversal: the buyer can time or withhold the payout and the merchant cannot settle unilaterally. Legal by design when buyer-controlled release IS the contract (buyer-claimed completion), silent otherwise per the C4 relaxation — service-binding and permission-role faces are merchant-side by construction and are NOT warned. Refund rails (slot-0 Order submission) are exempt: a buyer-triggered refund is the correct semantics.",
+          "scenario": "Buyer claims completion and fires the settlement rail; or withholds the signature and the merchant's revenue is stuck despite delivered work",
+          "mitigation": "If unilateral merchant settlement is intended, widen the rail's caller face to the C4-legal set: a permission.owner/admin role leg (riding the merchant permission rail 1000/1001) or an order.service binding leg plus the permission-index rail. Keep the buyer-only face only where buyer-controlled release is the contract.",
+          "evidence": "Scene: service_order_allocators_guard. Identity form: ${rc4_01_identity_form}. Comparison: ${rc4_01_comparison_ops}",
+          "stakeholders": ["customer", "provider"]
+        },
+        {
+          "when": { "all": [{ "field": "has_signer_check", "op": "eq", "value": true }, { "field": "rc4_01_identity_legal", "op": "falsy" }] },
+          "level": "medium",
+          "title": "Signer check direction needs manual confirmation (comparison operator and role match)",
+          "description": "Guard contains a context(Signer) check whose identity form is NOT in the C4-legal caller set (order.owner==signer | order.agent | order.service binding | permission.owner/admin role). 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) Prefer a C4-legal caller face (order.owner / order.agent / order.service binding / permission.owner-admin role);5) Cover both expected-pass and expected-fail scenarios in gen_passport tests",
+          "evidence": "Comparison: ${rc4_01_comparison_ops}. Identity form: ${rc4_01_identity_form}",
+          "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 multi-guard paths may cause unfair allocation",
+          "description": "A distribution call submits ONE guard; every allocator bound to that guard fires in vector order against the shrinking pool (the on-chain allocation). If a single guard binds multiple allocators with overlapping conditions, the pool is split repeatedly and later allocators may receive less than intended or abort on insufficient balance. For alternative business paths (settle vs refund), use DIFFERENT guards so the caller's guard choice selects exactly one path.",
+          "scenario": "Allocation path overlap: multiple allocators bound to the same guard all fire, draining the pool in unexpected order",
+          "mitigation": "1) Bind each business path (settle/refund/damage) to its OWN Guard object; 2) Make guard conditions mutually exclusive via guard logic, not list order; 3) When a waterfall IS intended (fee first, then split remainder), keep the shared guard and verify the vector order matches the intended payout sequence",
+          "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 NO name (empty)",
+      "cases": [
+        {
+          "when": { "field": "rx1_12_vague_count", "op": "gt", "value": 0 },
+          "level": "medium",
+          "title": "Submitted data entry has no name (retained_submission risk: caller may submit wrong data)",
+          "description": "Guard table has ${rx1_12_vague_count} b_submission=true entries with an EMPTY name.\nAn unnamed submission entry has no data contract on any layer: the caller sees neither a field identifier (table name) nor a human explanation (Guard description).\nThe 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\nNote: SHORT identifier-style names (e.g. 'order_id', 'delivery_node') are schema-conformant and are NOT a risk — do not rename them to natural-language sentences; table names are limited to 64 BCS characters and the SDK rejects longer values.",
+          "scenario": "Caller submits wrong data because no layer explains what the field expects; the Guard passes verification but the business logic is wrong",
+          "mitigation": "1) Give every submission entry a short identifier name (e.g. 'order_id', 'delivery_node') — max 64 BCS characters;\n2) Explain what each submitted field means (expected type, expected object role) in the Guard's 'description' field — that is the human-readable data contract, not the name;\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": "Unnamed 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"]
+        }
+      ]
+    }
+  ]
+}