@wowok/agent-mcp 2.3.16 → 2.4.1

package/dist/knowledge/guard-risk.js

@@ -0,0 +1,1046 @@
+function rootStr(ctx) {
+    return JSON.stringify(ctx.root).toLowerCase();
+}
+function hasSignerCheck(ctx) {
+    return JSON.stringify(ctx.root).includes('"Signer"');
+}
+function hasClockCheck(ctx) {
+    return JSON.stringify(ctx.root).includes('"Clock"');
+}
+function hasGuardSelfRef(ctx) {
+    return JSON.stringify(ctx.root).includes('"Guard"');
+}
+function hasWitness(root) {
+    const str = JSON.stringify(root);
+    return str.includes('"convert_witness"');
+}
+function queriesRepository(ctx) {
+    return rootStr(ctx).includes('repository');
+}
+function queriesProgress(ctx) {
+    return rootStr(ctx).includes('progress');
+}
+function extractWitnessCodes(root) {
+    const codes = [];
+    const str = JSON.stringify(root);
+    const matches = str.matchAll(/"convert_witness"\s*:\s*(\d+)/g);
+    for (const m of matches) {
+        const code = parseInt(m[1], 10);
+        if (code >= 100 && code <= 108)
+            codes.push(code);
+    }
+    return codes;
+}
+const RISK_RULES = [
+    {
+        id: "R-C1-01",
+        data_source_class: "type1_onchain_constant",
+        trigger: "Guard table contains Address constants with b_submission=false; values may change after Guard rebuild",
+        check: (ctx) => {
+            const constAddrEntries = ctx.table.filter((e) => !e.b_submission && e.value_type === "Address" && e.value);
+            if (constAddrEntries.length === 0)
+                return null;
+            return {
+                id: "R-C1-01",
+                data_source_class: "type1_onchain_constant",
+                level: "low",
+                category: "data_source_trust",
+                title: "Constant object addresses may be inconsistent after Guard rebuild",
+                description: `Guard table contains ${constAddrEntries.length} 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.",
+                affected_stakeholders: ["provider"],
+                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: ${constAddrEntries.map((e) => `#${e.identifier}=${e.value}`).join(", ")}`,
+            };
+        },
+    },
+    {
+        id: "R-C1-02",
+        data_source_class: "type1_onchain_constant",
+        trigger: "Guard table contains EntityRegistrar(0xaab) or EntityLinker(0xaaa) system address constants",
+        check: (ctx) => {
+            const sysAddrEntries = ctx.table.filter((e) => !e.b_submission &&
+                e.value_type === "Address" &&
+                typeof e.value === "string" &&
+                (e.value.toLowerCase() === "0xaab" || e.value.toLowerCase() === "0xaaa"));
+            if (sysAddrEntries.length === 0)
+                return null;
+            const wrong = sysAddrEntries.find((e) => (e.value === "0xaab" && e.name && !e.name.toLowerCase().includes("registrar")) ||
+                (e.value === "0xaaa" && e.name && !e.name.toLowerCase().includes("linker")));
+            return {
+                id: "R-C1-02",
+                data_source_class: "type1_onchain_constant",
+                level: wrong ? "medium" : "info",
+                category: "data_source_trust",
+                title: wrong
+                    ? "EntityRegistrar/EntityLinker system address name annotation suspected to be wrong"
+                    : "Guard uses EntityRegistrar/EntityLinker system address constants",
+                description: "EntityRegistrar (0xaab) and EntityLinker (0xaaa) are fixed WoWok protocol system addresses." +
+                    (wrong
+                        ? "Detected name annotation does not match the address (e.g. 0xaab not annotated as registrar), which may cause semantic misunderstanding."
+                        : "Address is correct, but ensure the name annotation is clear to avoid later maintenance confusion."),
+                affected_stakeholders: ["provider"],
+                scenario: "System address misuse: incorrect 0xaab/0xaaa name annotation causes query target confusion",
+                mitigation: "1) Confirm 0xaab corresponds to EntityRegistrar (entity registrar);" +
+                    "2) Confirm 0xaaa corresponds to EntityLinker (entity linker);" +
+                    "3) The table entry name should clearly indicate the system address purpose",
+                evidence: `System address entries: ${sysAddrEntries.map((e) => `#${e.identifier}=${e.value}(${e.name})`).join(", ")}`,
+            };
+        },
+    },
+    {
+        id: "R-C1-03",
+        data_source_class: "type1_onchain_constant",
+        trigger: "Guard queries Repository data without verifying writer permissions",
+        check: (ctx) => {
+            if (!queriesRepository(ctx))
+                return null;
+            if (hasSignerCheck(ctx))
+                return null;
+            return {
+                id: "R-C1-03",
+                data_source_class: "type1_onchain_constant",
+                level: "high",
+                category: "data_source_trust",
+                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.",
+                affected_stakeholders: ["customer", "provider"],
+                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",
+            };
+        },
+    },
+    {
+        id: "R-C2-01",
+        data_source_class: "type2_witness_derived",
+        trigger: "Guard uses multi-hop witness (106/107/108: Arb→Progress/Machine/Service) to derive target object",
+        check: (ctx) => {
+            const codes = extractWitnessCodes(ctx.root);
+            const multiHop = codes.filter((c) => [106, 107, 108].includes(c));
+            if (multiHop.length === 0)
+                return null;
+            const witnessNames = {
+                106: "Arb→Progress (two hops: arb.order → order.progress)",
+                107: "Arb→Machine (two hops: arb.order → order.machine)",
+                108: "Arb→Service (two hops: arb.order → order.service)",
+            };
+            return {
+                id: "R-C2-01",
+                data_source_class: "type2_witness_derived",
+                level: "medium",
+                category: "data_source_trust",
+                title: "Multi-hop witness chain derivation may break",
+                description: `Guard uses multi-hop witness [${multiHop.join(", ")}] 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" +
+                    multiHop.map((c) => `  - ${c}: ${witnessNames[c]}`).join("\n"),
+                affected_stakeholders: ["customer", "provider", "arbitrator"],
+                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: ${multiHop.join(", ")}`,
+            };
+        },
+    },
+    {
+        id: "R-C2-02",
+        data_source_class: "type2_witness_derived",
+        trigger: "Guard uses witness but source object's object_type may not match the witness source type",
+        check: (ctx) => {
+            const codes = extractWitnessCodes(ctx.root);
+            if (codes.length === 0)
+                return null;
+            const witnessSourceTypes = {
+                100: "Order", 101: "Order", 102: "Order",
+                103: "Progress",
+                104: "Arb", 105: "Arb", 106: "Arb", 107: "Arb", 108: "Arb",
+            };
+            const rootStr = JSON.stringify(ctx.root);
+            const mismatches = [];
+            for (const code of codes) {
+                const expectedSource = witnessSourceTypes[code];
+                if (!expectedSource)
+                    continue;
+                const pattern1 = new RegExp(`"identifier"\\s*:\\s*(\\d+)\\s*,\\s*"convert_witness"\\s*:\\s*${code}`, "g");
+                const pattern2 = new RegExp(`"convert_witness"\\s*:\\s*${code}\\s*,\\s*"identifier"\\s*:\\s*(\\d+)`, "g");
+                const foundIds = new Set();
+                let m;
+                while ((m = pattern1.exec(rootStr)) !== null) {
+                    foundIds.add(parseInt(m[1], 10));
+                }
+                while ((m = pattern2.exec(rootStr)) !== null) {
+                    foundIds.add(parseInt(m[1], 10));
+                }
+                for (const id of foundIds) {
+                    const entry = ctx.table.find((e) => e.identifier === id);
+                    if (entry?.object_type && entry.object_type !== expectedSource) {
+                        mismatches.push(`witness ${code}(${expectedSource}→?) references #${id} object_type=${entry.object_type}`);
+                    }
+                }
+            }
+            if (mismatches.length === 0)
+                return null;
+            return {
+                id: "R-C2-02",
+                data_source_class: "type2_witness_derived",
+                level: "low",
+                category: "data_source_trust",
+                title: "witness source object object_type may not match the witness source type",
+                description: "Guard uses witness derivation, but the source object's object_type in table is inconsistent with the witness expected source type.\n" +
+                    mismatches.map((mm) => `  - ${mm}`).join("\n") +
+                    "\nNote: object_type is an auxiliary annotation field on table entries; it is not strictly validated at on-chain creation." +
+                    "However, wrong annotations cause semantic misunderstanding and maintenance difficulty.",
+                affected_stakeholders: ["provider"],
+                scenario: "Type annotation mismatch: witness source type annotation is wrong, causing semantic confusion",
+                mitigation: "1) Fix the table entry's object_type field to match the witness source type;" +
+                    "2) witness 100-102 source type is Order; 103 is Progress; 104-108 is Arb;" +
+                    "3) Use wowok_buildin_info(info='guard instructions') to query the full witness definition",
+                evidence: mismatches.join("; "),
+            };
+        },
+    },
+    {
+        id: "R-C2-03",
+        data_source_class: "type2_witness_derived",
+        trigger: "Guard queries Progress status without verifying Machine publish state",
+        check: (ctx) => {
+            if (!queriesProgress(ctx))
+                return null;
+            if (!hasWitness(ctx.root))
+                return null;
+            if (ctx.scene?.host_object !== "Machine")
+                return null;
+            return {
+                id: "R-C2-03",
+                data_source_class: "type2_witness_derived",
+                level: "medium",
+                category: "data_source_trust",
+                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.",
+                affected_stakeholders: ["customer"],
+                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",
+            };
+        },
+    },
+    {
+        id: "R-C2-04",
+        data_source_class: "type2_witness_derived",
+        trigger: "Guard uses witness query and the query parameter requires type conversion (e.g. Address → U64 timestamp key)",
+        check: (ctx) => {
+            if (!hasWitness(ctx.root))
+                return null;
+            const str = rootStr(ctx);
+            const hasTypeConversion = str.includes("convert_number_address") ||
+                str.includes("convert_address_number") ||
+                str.includes("convert_u256") ||
+                str.includes("convert_string");
+            const queriesRepo = str.includes("repository") && str.includes('"query"');
+            const queriesProgressHistory = str.includes("progress_history") && str.includes('"query"');
+            if (!queriesRepo && !queriesProgressHistory)
+                return null;
+            return {
+                id: "R-C2-04",
+                data_source_class: "type2_witness_derived",
+                level: "medium",
+                category: "data_source_trust",
+                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.\n" +
+                    "Typical 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\n" +
+                    (hasTypeConversion
+                        ? "\nThe current Guard already uses type conversion nodes, but ensure the conversion direction is correct."
+                        : "\nWarning: no type conversion node detected in the current Guard; parameter type mismatch risk may exist."),
+                affected_stakeholders: ["provider", "customer"],
+                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;\n" +
+                    "2) If table declares Address but the query needs U64, use convert_number_address to translate;\n" +
+                    "3) Use wowok_buildin_info info='guard instructions' to verify parameter types;\n" +
+                    "4) Verify type compatibility via schema_query before creation",
+                evidence: hasTypeConversion ? "Type conversion node in use" : "No type conversion node detected",
+            };
+        },
+    },
+    {
+        id: "R-C3-01",
+        data_source_class: "type3_submitted_object",
+        trigger: "Guard depends on submitted data but does not verify signer identity (no Signer check=high; with Signer check=info downgrade)",
+        check: (ctx) => {
+            const hasSubmission = ctx.table.some((e) => e.b_submission);
+            if (!hasSubmission)
+                return null;
+            if (ctx.scene?.binding_field === "voting_guard")
+                return null;
+            if (!hasSignerCheck(ctx)) {
+                if (ctx.scene?.id === "machine_forward_guard") {
+                    return {
+                        id: "R-C3-01",
+                        data_source_class: "type3_submitted_object",
+                        level: "medium",
+                        category: "submission_forgery",
+                        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.",
+                        affected_stakeholders: ["customer", "provider"],
+                        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",
+                    };
+                }
+                return {
+                    id: "R-C3-01",
+                    data_source_class: "type3_submitted_object",
+                    level: "high",
+                    category: "submission_forgery",
+                    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.",
+                    affected_stakeholders: ["customer", "provider"],
+                    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",
+                };
+            }
+            return {
+                id: "R-C3-01",
+                data_source_class: "type3_submitted_object",
+                level: "info",
+                category: "submission_forgery",
+                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.",
+                affected_stakeholders: ["customer", "provider"],
+                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",
+            };
+        },
+    },
+    {
+        id: "R-C3-02",
+        data_source_class: "type3_submitted_object",
+        trigger: "voting_guard weight comes from submitted data without verifying source",
+        check: (ctx) => {
+            if (ctx.scene?.binding_field !== "voting_guard")
+                return null;
+            const numericEntries = ctx.table.filter((e) => e.b_submission &&
+                ["U8", "U16", "U32", "U64", "U128", "U256"].includes(e.value_type));
+            if (numericEntries.length === 0)
+                return null;
+            return {
+                id: "R-C3-02",
+                data_source_class: "type3_submitted_object",
+                level: "critical",
+                category: "submission_forgery",
+                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.",
+                affected_stakeholders: ["arbitrator"],
+                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: ${numericEntries.map((e) => `#${e.identifier}(${e.value_type})`).join(", ")}`,
+            };
+        },
+    },
+    {
+        id: "R-C3-03",
+        data_source_class: "type3_submitted_object",
+        trigger: "Guard contains Address entries with b_submission=true; the runtime submitted object type may not match expectations",
+        check: (ctx) => {
+            const submittedAddr = ctx.table.filter((e) => e.b_submission && e.value_type === "Address");
+            if (submittedAddr.length === 0)
+                return null;
+            const noType = submittedAddr.filter((e) => !e.object_type);
+            const hasQuery = rootStr(ctx).includes('"query"');
+            if (!hasQuery)
+                return null;
+            return {
+                id: "R-C3-03",
+                data_source_class: "type3_submitted_object",
+                level: noType.length > 0 ? "medium" : "low",
+                category: "submission_forgery",
+                title: noType.length > 0
+                    ? "Submitted object missing object_type annotation; runtime type validation relies on native inference"
+                    : "Submitted object type validation relies on runtime native inference",
+                description: "Guard contains " + submittedAddr.length + " 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.\n" +
+                    (noType.length > 0
+                        ? `Warning: ${noType.length} entries are missing object_type annotation, semantics are unclear.`
+                        : "object_type is annotated, but still confirm the annotation matches what the query expects."),
+                affected_stakeholders: ["customer", "provider"],
+                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: noType.length > 0
+                    ? `Missing object_type: ${noType.map((e) => `#${e.identifier}`).join(", ")}`
+                    : `Annotated: ${submittedAddr.map((e) => `#${e.identifier}=${e.object_type}`).join(", ")}`,
+            };
+        },
+    },
+    {
+        id: "R-C3-04",
+        data_source_class: "type3_submitted_object",
+        trigger: "Repository write_guard does not verify id_from_submission type",
+        check: (ctx) => {
+            if (ctx.scene?.binding_field !== "write_guard")
+                return null;
+            return {
+                id: "R-C3-04",
+                data_source_class: "type3_submitted_object",
+                level: "high",
+                category: "binding_risk",
+                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.",
+                affected_stakeholders: ["provider"],
+                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",
+            };
+        },
+    },
+    {
+        id: "R-C4-01",
+        data_source_class: "type4_system_context",
+        trigger: "Guard contains context(Signer) check; need to confirm comparison direction (== vs !=) and compared object role",
+        check: (ctx) => {
+            if (!hasSignerCheck(ctx))
+                return null;
+            const rootStrRaw = JSON.stringify(ctx.root);
+            const hasEqual = rootStrRaw.includes('"logic_equal"');
+            const hasNotEqual = rootStrRaw.includes('"logic_not_equal"');
+            return {
+                id: "R-C4-01",
+                data_source_class: "type4_system_context",
+                level: "medium",
+                category: "system_context_risk",
+                title: "Signer check direction needs manual confirmation (comparison operator and role match)",
+                description: "Guard contains a context(Signer) check. Signer is a Type4 system context, " +
+                    "from TransactionContext.sender() (transaction initiator address).\n" +
+                    `Detected comparison: ${hasEqual ? "logic_equal(==)" : ""} ${hasNotEqual ? "logic_not_equal(!=)" : ""}\n` +
+                    "Manual 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",
+                affected_stakeholders: ["customer", "provider"],
+                scenario: "Wrong direction: Signer == blacklist address would only allow blacklisted users",
+                mitigation: "1) Confirm logic_equal is used for identity verification (Signer == authorized address);" +
+                    "2) Confirm logic_not_equal is used for exclusion (Signer != blacklist address);" +
+                    "3) Confirm the compared table constant is the address of the correct role;" +
+                    "4) Cover both expected-pass and expected-fail scenarios in gen_passport tests",
+                evidence: `Comparison: ${hasEqual ? "==" : ""} ${hasNotEqual ? "!=" : ""}`,
+            };
+        },
+    },
+    {
+        id: "R-C4-02",
+        data_source_class: "type4_system_context",
+        trigger: "Guard uses context(Clock) for precise boundary time-lock comparison",
+        check: (ctx) => {
+            if (!hasClockCheck(ctx))
+                return null;
+            const str = rootStr(ctx);
+            const hasGreaterOrEqual = str.includes("logic_as_u256_greater_or_equal");
+            const hasGreater = str.includes("logic_as_u256_greater");
+            if (!hasGreaterOrEqual && !hasGreater)
+                return null;
+            return {
+                id: "R-C4-02",
+                data_source_class: "type4_system_context",
+                level: "low",
+                category: "system_context_risk",
+                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.\n" +
+                    "The Sui 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\n" +
+                    "It is recommended to use > instead of >=, or add a small tolerance constant.",
+                affected_stakeholders: ["customer", "provider"],
+                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: ${hasGreaterOrEqual ? ">=" : ""} ${hasGreater ? ">" : ""}`,
+            };
+        },
+    },
+    {
+        id: "R-C4-03",
+        data_source_class: "type4_system_context",
+        trigger: "Guard uses context(Guard) self-reference",
+        check: (ctx) => {
+            if (!hasGuardSelfRef(ctx))
+                return null;
+            return {
+                id: "R-C4-03",
+                data_source_class: "type4_system_context",
+                level: "info",
+                category: "system_context_risk",
+                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.\n" +
+                    "This 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)\n" +
+                    "Need to confirm whether the use of context(Guard) is necessary and whether the comparison object is correct.",
+                affected_stakeholders: ["provider"],
+                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",
+            };
+        },
+    },
+    {
+        id: "R-X1-01",
+        data_source_class: "cross_type",
+        trigger: "Time-lock query returns 0 causing logic_as_u256_greater_or_equal comparison to always be true",
+        check: (ctx) => {
+            const str = rootStr(ctx);
+            const hasGreaterOrEqual = str.includes("logic_as_u256_greater_or_equal");
+            const hasClock = str.includes('"clock"');
+            const hasCalcAdd = str.includes("calc_number_add");
+            const hasQuery = str.includes('"query"');
+            if (!(hasGreaterOrEqual && hasClock && hasCalcAdd && hasQuery))
+                return null;
+            return {
+                id: "R-X1-01",
+                data_source_class: "cross_type",
+                level: "medium",
+                category: "logic_gap",
+                title: "Time-lock 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 returns 0 (e.g. querying a timestamp of an operation that hasn't happened, or unset node entry time), " +
+                    "then Clock >= 0 + timeout is always true, the time-lock is effectively void, and the disadvantaged party can bypass the time constraint immediately.",
+                affected_stakeholders: ["customer", "provider"],
+                scenario: "Time-lock invalidation: query returns 0, making the >= condition always pass",
+                mitigation: "1) Use a query that returns the current node entry time (e.g. progress.current_time, id=1272) " +
+                    "instead of the operation timestamp (e.g. progress.session.forward.time, id=1271);" +
+                    "2) Add a precondition check query > 0 before the time-lock;" +
+                    "3) Confirm the query must have a value when the Guard executes (query current node attributes rather than historical operations)",
+            };
+        },
+    },
+    {
+        id: "R-X1-02",
+        data_source_class: "cross_type",
+        trigger: "Guard uses logic_as_u256_greater but does not handle null values",
+        check: (ctx) => {
+            const str = rootStr(ctx);
+            if (!(str.includes("logic_as_u256_greater") && str.includes('"query"')))
+                return null;
+            return {
+                id: "R-X1-02",
+                data_source_class: "cross_type",
+                level: "medium",
+                category: "logic_gap",
+                title: "Numeric comparison does not handle the case of query returning null",
+                description: "Guard uses logic_as_u256_greater for numeric comparison, and operands come from a query (Type1/2/3 data sources)." +
+                    "If the query returns null (e.g. object does not exist, field not set), the comparison result may be undefined." +
+                    "In the WoWok protocol null is usually treated as 0, which may cause unexpected pass.",
+                affected_stakeholders: ["customer", "provider"],
+                scenario: "Null misjudgment: query returns 0, causing > 0 condition to unexpectedly pass or fail",
+                mitigation: "1) Add a query result existence check before comparison;" +
+                    "2) Use query_reward_record_exists or query_progress_history_find to verify first;" +
+                    "3) Consider adding a logic_and(object exists, numeric comparison) combination",
+            };
+        },
+    },
+    {
+        id: "R-X1-03",
+        data_source_class: "cross_type",
+        trigger: "Guard uses logic_string_contains and may be bypassed by substring matching",
+        check: (ctx) => {
+            const str = rootStr(ctx);
+            if (!(str.includes("logic_string_contains") && !str.includes("logic_string_nocase")))
+                return null;
+            return {
+                id: "R-X1-03",
+                data_source_class: "cross_type",
+                level: "low",
+                category: "logic_gap",
+                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.",
+                affected_stakeholders: ["customer", "provider"],
+                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)",
+            };
+        },
+    },
+    {
+        id: "R-X1-04",
+        data_source_class: "cross_type",
+        trigger: "Guard root is an identifier directly returning Bool",
+        check: (ctx) => {
+            if (ctx.root?.type !== "identifier")
+                return null;
+            const entry = ctx.table.find((e) => e.identifier === ctx.root.identifier);
+            const isSubmission = entry?.b_submission ?? false;
+            return {
+                id: "R-X1-04",
+                data_source_class: "cross_type",
+                level: isSubmission ? "medium" : "low",
+                category: "logic_gap",
+                title: "Root directly returns identifier value, no operation logic",
+                description: "Guard root is an identifier node, directly returning the value (Bool) from table." +
+                    (isSubmission
+                        ? "This entry has b_submission=true (Type3 submitted value); the caller can directly submit true to bypass all verification."
+                        : "This entry has b_submission=false (Type1 constant); the value is fixed but the Guard has no actual verification logic."),
+                affected_stakeholders: ["customer", "provider"],
+                scenario: isSubmission
+                    ? "Bypass verification: caller submits true to pass the Guard directly"
+                    : "No verification logic: Guard always returns a fixed value, providing no actual protection",
+                mitigation: isSubmission
+                    ? "1) Ensure the entry referenced by identifier has b_submission=false (constant);" +
+                        "2) Or add an additional logic_and condition for cross-validation"
+                    : "1) Add actual verification logic (query + logic comparison);" +
+                        "2) Evaluate whether this Guard needs to exist",
+            };
+        },
+    },
+    {
+        id: "R-X1-05",
+        data_source_class: "cross_type",
+        trigger: "Allocation Guard may cause some participants to be skipped",
+        check: (ctx) => {
+            if (ctx.scene?.binding_field !== "order_allocators")
+                return null;
+            return {
+                id: "R-X1-05",
+                data_source_class: "cross_type",
+                level: "medium",
+                category: "game_theory",
+                title: "order_allocators first-match-wins may cause unfair allocation",
+                description: "order_allocators uses a first-match-wins strategy: the first Allocator whose Guard passes executes the allocation." +
+                    "If the order is poorly designed, some participants may never get allocated." +
+                    "For example: if the first Allocator's Guard condition is too broad, subsequent more precise Allocators will never execute." +
+                    "Allocation Guards typically combine Type1 (query order fields), Type3 (submit Order address), and Type4 (Signer) data.",
+                affected_stakeholders: ["provider"],
+                scenario: "Allocation skip: the Provider's allocation Allocator is skipped by preceding broad conditions",
+                mitigation: "1) Ensure the order_allocators order goes from strict to loose;" +
+                    "2) Each Allocator's Guard conditions should be mutually exclusive;" +
+                    "3) Consider using logic_or dependencies rather than sequential ordering",
+            };
+        },
+    },
+    {
+        id: "R-X1-06",
+        data_source_class: "cross_type",
+        trigger: "Workflow Guard time-lock may lock the disadvantaged party",
+        check: (ctx) => {
+            const str = rootStr(ctx);
+            if (!(str.includes("clock") && str.includes("calc_number_add")))
+                return null;
+            return {
+                id: "R-X1-06",
+                data_source_class: "cross_type",
+                level: "medium",
+                category: "game_theory",
+                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.",
+                affected_stakeholders: ["customer", "provider"],
+                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",
+            };
+        },
+    },
+    {
+        id: "R-X1-07",
+        data_source_class: "cross_type",
+        trigger: "Arbitration usage_guard may block legitimate disputes",
+        check: (ctx) => {
+            if (ctx.scene?.binding_field !== "usage_guard")
+                return null;
+            const str = rootStr(ctx);
+            const andCount = (str.match(/"logic_and"/g) || []).length;
+            if (andCount < 3)
+                return null;
+            return {
+                id: "R-X1-07",
+                data_source_class: "cross_type",
+                level: "high",
+                category: "game_theory",
+                title: "usage_guard has too many conditions and may block legitimate disputes",
+                description: `Detected ${andCount} 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.",
+                affected_stakeholders: ["customer"],
+                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",
+            };
+        },
+    },
+    {
+        id: "R-X1-08",
+        data_source_class: "cross_type",
+        trigger: "Guard is bound to a published Machine/Service (immutable)",
+        check: (ctx) => {
+            if (!ctx.scene || ctx.scene.mutable_after_publish)
+                return null;
+            return {
+                id: "R-X1-08",
+                data_source_class: "cross_type",
+                level: "info",
+                category: "binding_risk",
+                title: `Guard is bound to immutable ${ctx.scene.host_object} (cannot be modified after publish)`,
+                description: `After ${ctx.scene.host_object} is published, ${ctx.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.",
+                affected_stakeholders: ["provider"],
+                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",
+            };
+        },
+    },
+    {
+        id: "R-X1-09",
+        data_source_class: "cross_type",
+        trigger: "Guard uses rely but the dependent Guard may fail",
+        check: (ctx) => {
+            if (!ctx.rely || ctx.rely.guards.length === 0)
+                return null;
+            const logic = ctx.rely.logic_or ? "OR" : "AND";
+            return {
+                id: "R-X1-09",
+                data_source_class: "cross_type",
+                level: ctx.rely.logic_or ? "low" : "medium",
+                category: "dependency_risk",
+                title: `rely ${logic} depends on ${ctx.rely.guards.length} external Guards`,
+                description: `Guard uses rely ${logic} to depend on ${ctx.rely.guards.length} external Guards.` +
+                    (ctx.rely.logic_or
+                        ? "OR logic: any one passing is enough. If a dependent Guard is loosely designed, it may become a bypass entry point."
+                        : "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).",
+                affected_stakeholders: ["customer", "provider"],
+                scenario: ctx.rely.logic_or
+                    ? "Dependency bypass: a loose dependent Guard becomes an attack entry point"
+                    : "Dependency failure: a dependent Guard is deleted, causing the current Guard to always fail",
+                mitigation: ctx.rely.logic_or
+                    ? "1) Review the strictness of each dependent Guard; 2) Ensure all dependent Guards are at least as strict as the current Guard"
+                    : "1) Confirm all dependent Guards have rep=true and cannot be deleted; 2) Consider whether AND dependency is truly needed",
+            };
+        },
+    },
+    {
+        id: "R-X1-10",
+        data_source_class: "cross_type",
+        trigger: "Guard uses repository.data query (query 1167) and the Repository has quote_guard set",
+        check: (ctx) => {
+            const str = rootStr(ctx);
+            if (!(str.includes("repository") && str.includes('"query"')))
+                return null;
+            return {
+                id: "R-X1-10",
+                data_source_class: "cross_type",
+                level: "medium",
+                category: "impack_risk",
+                title: "repository.data query's quote_guard is invalid in the verify phase (impack_list is empty)",
+                description: "Guard queries repository.data (query 1167). According to passport.move#L289 and passport.rs implementation, " +
+                    "the impack_list is always empty in the verify phase (only filled after result_for_permission).\n" +
+                    "Therefore in check_repository_quote_guard (inside query 1167), " +
+                    "if the Repository policy's quote_guard is Some(addr), " +
+                    "since addr is not in the empty list, it will always report IMPACK_GUARD_NOT_FOUND.\n" +
+                    "Only when quote_guard==None can query 1167 pass.\n" +
+                    "This means: querying Repository data with a quote_guard in the Guard will always fail.",
+                affected_stakeholders: ["customer", "provider"],
+                scenario: "quote_guard invalidation: impack_list is empty in the verify phase, causing the 1167 query to always fail",
+                mitigation: "1) Confirm the queried Repository's quote_guard is None;" +
+                    "2) If quote authentication is needed, modify the verify loop in the Move layer to maintain impack_list;" +
+                    "3) Document this limitation clearly: Repositories with quote_guard cannot be queried in the Guard;" +
+                    "4) Consider using other data sources instead of Repository.data query",
+            };
+        },
+    },
+    {
+        id: "R-X1-11",
+        data_source_class: "cross_type",
+        trigger: "Guard uses rely to depend on other Guards; need to confirm the rep flag of dependent Guards is correct",
+        check: (ctx) => {
+            if (!ctx.rely || ctx.rely.guards.length === 0)
+                return null;
+            const str = rootStr(ctx);
+            const queriesRepoData = str.includes("repository") && str.includes('"query"');
+            const hasRepoSubmission = ctx.table.some((e) => e.b_submission && e.value_type === "Address" && e.object_type === "Repository");
+            return {
+                id: "R-X1-11",
+                data_source_class: "cross_type",
+                level: queriesRepoData && hasRepoSubmission ? "medium" : "low",
+                category: "rep_risk",
+                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.\n" +
+                    "Precise 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\n" +
+                    "Guards with rep=false cannot appear in other Guards' rely lists.\n" +
+                    (queriesRepoData && hasRepoSubmission
+                        ? "\nWarning: the current Guard itself queries repository.data and the Repository address comes from submission, " +
+                            "so its own rep=false and cannot be depended on by other Guards."
+                        : ""),
+                affected_stakeholders: ["provider"],
+                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: queriesRepoData && hasRepoSubmission
+                    ? "Self rep=false (repository.data query depends on submission)"
+                    : "Self rep status to be confirmed",
+            };
+        },
+    },
+    {
+        id: "R-X1-12",
+        data_source_class: "cross_type",
+        trigger: "Guard table contains b_submission=true entries with vague name descriptions or missing binding_constraint",
+        check: (ctx) => {
+            const submissionEntries = ctx.table.filter((e) => e.b_submission);
+            if (submissionEntries.length === 0)
+                return null;
+            const vagueEntries = submissionEntries.filter((e) => {
+                const name = e.name ?? "";
+                return name.length < 10 || /^[a-z_]+$/i.test(name) || name === "";
+            });
+            if (vagueEntries.length === 0)
+                return null;
+            return {
+                id: "R-X1-12",
+                data_source_class: "cross_type",
+                level: "medium",
+                category: "submission_forgery",
+                title: "Submitted data entry description is vague (retained_submission risk: caller may submit wrong data)",
+                description: `Guard table has ${vagueEntries.length} b_submission=true entries with vague name descriptions.\n` +
+                    "The name of a submission entry is the only data contract between the Guard and the caller.\n" +
+                    "If the name description is unclear (e.g. only 'addr' / 'order_id'), the caller may:\n" +
+                    "  - Submit a wrong-typed object address (e.g. submit a Service address instead of an Order address)\n" +
+                    "  - Submit a wrong value (e.g. inconsistent amount units)\n" +
+                    "  - Confuse submission slots of different Guards in multi-Guard scenarios\n" +
+                    "Vague submission entries are 'retained' in the table but provide no effective data constraints, " +
+                    "equivalent to the Guard accepting arbitrary data without validating its semantic correctness.",
+                affected_stakeholders: ["customer", "provider"],
+                scenario: "Caller submits wrong data due to vague name description; the Guard passes verification but the business logic is wrong",
+                mitigation: "1) Each submission entry's name should be a complete natural-language description (e.g. 'The order ID that identifies the target Order for verification');\n" +
+                    "2) Avoid Technical identifiers as name (e.g. 'order_id' should become 'Order ID, used to query progress status');\n" +
+                    "3) Add failure_conditions in binding_hint to clarify failure scenarios;\n" +
+                    "4) Consider adding type validation logic in root (e.g. query the submitted object's objectType and match with expectation)",
+                evidence: `Vague entries: ${vagueEntries.map((e) => `identifier=${e.identifier}, name="${e.name}"`).join("; ")}`,
+            };
+        },
+    },
+    {
+        id: "R-X1-13",
+        data_source_class: "cross_type",
+        trigger: "Guard references its host object (Host Object) itself — circular reference pattern",
+        check: (ctx) => {
+            if (!ctx.scene)
+                return null;
+            const hostType = ctx.scene.host_object;
+            const circularEntry = ctx.table.find((e) => !e.b_submission && e.value_type === "Address" &&
+                e.object_type === hostType);
+            if (!circularEntry)
+                return null;
+            return {
+                id: "R-X1-13",
+                data_source_class: "cross_type",
+                level: "medium",
+                category: "binding_risk",
+                title: "Circular reference pattern (Guard references the host object itself; note creation order)",
+                description: `In the Guard's table, identifier=${circularEntry.identifier} has object_type equal to the host object type "${hostType}".\n` +
+                    "Circular reference pattern: the Guard is bound to a Host Object (e.g. Service.buy_guard) and also queries the Host Object's own fields.\n" +
+                    "Creation 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\n" +
+                    "Risks:\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)",
+                affected_stakeholders: ["provider"],
+                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;\n" +
+                    "2) Use the Host Object's name rather than address in table (the SDK auto-resolves);\n" +
+                    "3) Perform Guard verification tests after the Host Object is published;\n" +
+                    "4) Use guard2file to export a Guard backup for restoring references during rebuild",
+                evidence: `Circular reference: identifier=${circularEntry.identifier}, object_type="${hostType}" → ${ctx.scene.host_object}`,
+            };
+        },
+    },
+];
+export function assessGuardRisks(params) {
+    const ctx = {
+        table: params.table,
+        root: params.root,
+        rely: params.rely,
+        scene: params.scene,
+        operation_type: params.operation_type,
+    };
+    const risks = [];
+    for (const rule of RISK_RULES) {
+        try {
+            const risk = rule.check(ctx);
+            if (risk)
+                risks.push(risk);
+        }
+        catch {
+        }
+    }
+    const overall_risk = getOverallRiskLevel(risks);
+    const risks_by_data_source = {};
+    for (const risk of risks) {
+        risks_by_data_source[risk.data_source_class] =
+            (risks_by_data_source[risk.data_source_class] ?? 0) + 1;
+    }
+    const stakeholder_advice = generateStakeholderAdvice(risks, params.scene);
+    const needs_human_review = risks.some((r) => r.level === "critical") ||
+        risks.filter((r) => r.level === "high").length >= 2;
+    const guard_summary = generateGuardSummary(params);
+    return {
+        guard_summary,
+        scene: params.scene,
+        risks,
+        overall_risk,
+        risks_by_data_source,
+        stakeholder_advice,
+        needs_human_review,
+    };
+}
+function getOverallRiskLevel(risks) {
+    if (risks.some((r) => r.level === "critical"))
+        return "critical";
+    if (risks.some((r) => r.level === "high"))
+        return "high";
+    if (risks.some((r) => r.level === "medium"))
+        return "medium";
+    if (risks.some((r) => r.level === "low"))
+        return "low";
+    return "info";
+}
+function generateStakeholderAdvice(risks, scene) {
+    const advice = {};
+    for (const risk of risks) {
+        for (const stakeholder of risk.affected_stakeholders) {
+            if (!advice[stakeholder])
+                advice[stakeholder] = [];
+            advice[stakeholder].push(`[${risk.level.toUpperCase()}] ${risk.title}: ${risk.mitigation}`);
+        }
+    }
+    if (scene) {
+        switch (scene.binding_field) {
+            case "buy_guard":
+                if (!advice.customer)
+                    advice.customer = [];
+                advice.customer.push("Before purchase, verify the buy_guard logic to ensure your identity/credentials can pass validation");
+                break;
+            case "order_allocators":
+                if (!advice.provider)
+                    advice.provider = [];
+                advice.provider.push("Verify the order_allocators ordering to ensure your Allocator will not be skipped by preceding conditions");
+                break;
+            case "voting_guard":
+                if (!advice.arbitrator)
+                    advice.arbitrator = [];
+                advice.arbitrator.push("Confirm the voting weight source is trustworthy; prefer querying EntityRegistrar rather than user-submitted data");
+                break;
+            case "Forward.guard":
+                if (!advice.customer)
+                    advice.customer = [];
+                advice.customer.push("Verify the Forward.guard conditions to ensure you can satisfy the advancement criteria and avoid locked funds");
+                break;
+        }
+    }
+    return advice;
+}
+function generateGuardSummary(params) {
+    const parts = [];
+    parts.push(`table entries: ${params.table.length}`);
+    const submissions = params.table.filter((e) => e.b_submission).length;
+    parts.push(`submitted data: ${submissions} entries`);
+    parts.push(`root type: ${params.root?.type ?? "unknown"}`);
+    if (params.rely) {
+        parts.push(`rely: ${params.rely.guards.length} dependencies (${params.rely.logic_or ? "OR" : "AND"})`);
+    }
+    return parts.join(", ");
+}
+export function assessGuardRisksForOperation(operation_type, data) {
+    if (operation_type !== "guard")
+        return null;
+    const table = data?.table ?? [];
+    const root = data?.root;
+    const rely = data?.rely;
+    let scene;
+    return assessGuardRisks({ table, root, rely, scene, operation_type });
+}
+export function getRiskSummary(assessment) {
+    return {
+        risk_count: assessment.risks.length,
+        critical_count: assessment.risks.filter((r) => r.level === "critical").length,
+        high_count: assessment.risks.filter((r) => r.level === "high").length,
+        needs_human_review: assessment.needs_human_review,
+        top_risks: assessment.risks
+            .filter((r) => r.level === "critical" || r.level === "high")
+            .slice(0, 3)
+            .map((r) => r.title),
+    };
+}
+export function getRiskRulesByDataSourceClass(dataSourceClass) {
+    return RISK_RULES.filter((r) => r.data_source_class === dataSourceClass);
+}
+export function getAllRiskRules() {
+    return RISK_RULES;
+}
+export function getRiskRulesCount() {
+    return RISK_RULES.length;
+}