Code change approval control method and computer program product

Abstract

The disclosure provides a code change approval control method and a computer program product. A decision memory library containing constraint decisions and their feature matching conditions and risk identification strategies is constructed in advance. In response to a code change event, a change node is determined by parsing the code text, the context syntax structure features and / or the context code semantic features of the change node are extracted and matched with the decision memory library to hit the constraint decisions, the risk level of the change node is determined according to the risk identification strategy of the hit constraint decision, and the risk control operation is performed on the audit interface based on the risk level, including blocking the approval when the risk is high, and removing the block after receiving the architecture compromise background information that meets the legality requirements and rewriting the compromise decision to the decision memory library to establish an association. The technical scheme provided by the disclosure embeds the code architecture constraint decision into the code change approval process, and controls and traces the risk of the code change approval that violates the standard code architecture.

Description

Technical Field

[0001] This disclosure relates to the field of software engineering technology, specifically to a control method for code change approval and a computer program product. Background Technology

[0002] Existing code change review mechanisms primarily rely on text-based diff comparison tools to highlight added, deleted, and modified code, supplemented by static code analysis tools for syntax and known vulnerability checks. However, existing text-based diff comparison tools can only calculate which lines of text were modified and cannot assess the impact of code changes on the overall code architecture. This makes it easy for code changes that negatively impact the code architecture to be approved.

[0003] Therefore, a technical solution is needed to effectively control code change reviews. Summary of the Invention

[0004] This disclosure provides a control method and computer program product for code change approval, which adopts the following technical solution:

[0005] A control method for code change approval includes pre-constructing a decision memory, which at least includes several constraint decisions for standardizing code architecture. Each constraint decision is associated with feature matching conditions and a risk identification strategy. The method includes: in response to a code change event, acquiring code text related to the code change event, and performing syntax tree parsing based on the code text to determine one or more syntax tree nodes involved in the code change as change nodes; for each change node, extracting contextual syntax structure features and / or contextual code semantic features corresponding to the change node; matching the contextual syntax structure features and / or contextual code semantic features corresponding to the change node with the feature matching conditions associated with the constraint decisions in the decision memory to obtain the constraint decisions matched by the change node; determining the risk level of the change node according to the risk identification strategy associated with the constraint decisions matched by the change node; and performing risk control operations in the code review interface according to the risk level of each change node. The risk control operations at least include: blocking the approval operation for the code change event in response to the existence of at least one change node with a high risk level.

[0006] The above solution pre-builds a decision memory bank containing constraint decisions. When code changes, it extracts the context features of the changed nodes based on syntax tree parsing and matches them with the decision memory bank to determine the risk level. Then, based on the risk level, it performs risk control operations including high-risk blocking and compromise write-back. This enables code change review to assess the impact of changes on the standard code architecture and effectively control changes that affect the architecture.

[0007] As one implementation method, obtaining the code text related to the code change event includes: obtaining the code text of the file involved in the code change event before the change and the code text after the change; performing syntax tree parsing based on the code text includes: performing syntax tree parsing on the code text before the change and the code text after the change respectively to generate a syntax tree before the change and a syntax tree after the change; determining one or more syntax tree nodes involved in the code change as change nodes includes: performing structured alignment on the syntax tree before the change and the syntax tree after the change to generate a set of syntax tree editing operations, and determining the one or more syntax tree nodes according to the set of syntax tree editing operations.

[0008] This implementation method simultaneously acquires the code text before and after the change, parses it to generate a syntax tree, and then performs structured alignment. This allows the determination of change nodes to be based on structural differences at the syntax tree level rather than differences in text lines, thus improving the accuracy of change node identification.

[0009] As one implementation, a structured alignment is performed on the syntax tree before the change and the syntax tree after the change to generate a set of syntax tree editing operations, including: determining the isomorphic mapping relationship between the syntax tree before the change and the syntax tree after the change; for syntax tree nodes that have not established isomorphic mapping, generating at least one syntax tree editing operation among insertion, deletion, update or movement to obtain a set of syntax tree editing operations.

[0010] As one implementation, before determining the one or more change nodes based on the set of syntax tree editing operations, the method further includes: performing semantic noise filtering on the set of syntax tree editing operations and discarding syntax tree editing operations involving semantic noise; wherein, syntax tree editing operations involving semantic noise include at least one of whitespace characters, comments, formatting, and renaming; and syntax tree editing operations not involving semantic noise include at least one of control flow, business logic, state judgment, exception handling, call relationships, and architectural boundaries.

[0011] This implementation improves the accuracy and efficiency of risk identification by filtering semantic noise, allowing risk identification to focus on structural variations rather than textual changes that have no substantial semantic impact.

[0012] As one implementation method, extracting the contextual grammatical structure features and / or contextual code semantic features corresponding to the changed node includes: taking the changed node as the processing object, obtaining the node basic information, host context information, and local context information corresponding to the changed node; wherein, the node basic information includes the change operation type and node type, the host context information is used to characterize the upper-level grammatical structure of the changed node in the syntax tree, and the local context information is used to characterize the local grammatical structure and local code content of the changed node itself and its subtrees; and generating the contextual grammatical structure features and / or contextual code semantic features corresponding to the changed node based on the node basic information, the host context information, and the local context information.

[0013] This implementation extracts the contextual features of the changed node from three dimensions: basic node information, host context information, and local context information, providing a more comprehensive feature base for subsequent matching with the decision memory.

[0014] As one implementation method, obtaining the host context information includes: traversing upwards along the parent node pointer from the starting point of the changed node until the root node of the syntax tree is reached or a preset stopping condition is met, and extracting at least one of the following during the traversal: file path, package name, class name, function name, method signature, control block type, call path, and exception handling structure of the changed node; obtaining the local context information includes: traversing the subtree of the changed node from the starting point of the changed node, and extracting at least one of the following: child node type, conditional expression structure, branch structure, loop structure, call expression structure, return statement structure, literal node type, maximum nesting depth, and syntax tree depth of the changed node.

[0015] This implementation obtains host context information by traversing upwards along the parent node pointer and obtains local context information by traversing the subtree, so that context features can simultaneously reflect the macroscopic location and microscopic structure of the change node in the syntax tree, thus improving the completeness of feature extraction.

[0016] As one implementation method, extracting the contextual syntax structure features corresponding to the change node includes: extracting the contextual syntax structure features corresponding to the change node based on at least one of the following: change operation type, node type, parent node type, child node type, file path, class name, method signature, control block type, call path, exception handling structure, syntax tree depth, maximum nesting depth, number of conditional expressions, number of branches, number of loop structures, cyclomatic complexity increment, literal node type, and hit anti-pattern markers; wherein, the anti-pattern markers include hard-coded temporary mapping markers, or, unbounded enumeration markers; the unbounded enumeration markers are at least used to characterize the syntax tree structure in the switch statement that uses string literals as branch matching values; the hard-coded temporary mapping markers are at least used to characterize the syntax tree structure in the if statement that uses string literals as comparison objects.

[0017] This implementation improves the hit rate for architectural violation patterns by extracting various syntactic structural features, including anti-pattern markers, enabling feature matching to identify common anti-patterns such as hard-coded temporary mappings and unbounded enumerations.

[0018] As one implementation method, extracting the context code semantic features corresponding to the change node includes: extracting the context code semantic features of the change node based on at least one of the following: code snippet, file path, package name, class name, method signature, variable identifier, state variable identifier, function call identifier, call object identifier, literal value, condition judgment semantics, return statement semantics, exception handling semantics, business domain identifier, and anti-pattern marker.

[0019] This implementation extracts various code semantic features, including business domain identifiers and anti-pattern markers, enabling feature matching to identify the business meaning and violation tendencies of code changes at the semantic level, thereby improving the recall capability for deep architectural constraints.

[0020] As one implementation, the method further includes: generating a structured information payload to characterize the code change event; wherein the structured information payload includes at least one or more change node items, and each change node item includes one or more fields for recording the context syntax structure features and / or context code semantic features corresponding to the change node.

[0021] This implementation method generates a structured information payload, providing a structured data carrier for subsequent risk quantification calculations and interface display, facilitating unified access to change node information at each stage.

[0022] As one implementation, each change node item includes at least the following fields: node identifier field, change operation type field, node type field, code snippet field, context information field, and structure information field; the context information field includes at least one of class name field, method signature field, and syntax tree depth field; the structure information field includes at least one of cyclomatic complexity increment field, static anti-pattern hit tag field, and literal field.

[0023] This implementation defines specific fields for change node items, enabling the structured information payload to accurately record the key attributes of each change node, providing fine-grained data support for risk scoring and risk basis display.

[0024] As one implementation, the structured information payload further includes code change basic information items; the code change basic information items include a code change record identifier field and a code file path field involving code changes.

[0025] This implementation adds basic information items about code changes, enabling the structured information payload to be associated with the overall information of the code change event, making it easier to display the macro background of the change in the review interface.

[0026] In one implementation, the decision memory includes a graph database storing several constraint decision nodes and several code pattern nodes in a directed graph topology. Each constraint decision node includes at least a constraint intent field and a syntax tree trigger field, the syntax tree trigger field including a syntax tree trigger expression. Each code pattern node includes at least a syntax tree query field, including a syntax tree query expression. Each code pattern node is connected to at least some constraint decision nodes via directed trigger relationship edges, indicating that when the code pattern node is directly matched, the corresponding constraint decision node is indirectly matched along the directed trigger relationship edge. The upper and lower corresponding nodes of the change node are... The context syntax structure features of the change node are matched with the feature matching conditions associated with the constraint decisions in the decision memory to obtain the constraint decisions that the change node is matched with. This includes: matching the context syntax structure features corresponding to the change node with the syntax tree trigger field of the constraint decision node in the graph database to obtain directly matched constraint decision nodes; matching the context syntax structure features corresponding to the change node with the syntax tree query field of the code pattern node in the graph database to obtain indirectly matched constraint decision nodes; and merging and deduplicating the directly matched constraint decisions and the indirectly matched constraint decisions to obtain the constraint decision nodes that the change node is matched with.

[0027] This implementation stores constraint decision nodes and code pattern nodes in a graph database and connects them with directed triggering edges, enabling constraint decision matching to support both direct hits and indirect hits through code patterns, thereby improving the coverage of constraints in complex architectures.

[0028] In one implementation, the constraint decision node in the graph database further includes at least one of a node identifier field, a node version number field, and a node type label field; or the constraint decision node in the graph database further includes at least one of a risk weight and a risk control operation level; or the constraint decision node in the graph database further includes a replacement relationship field, used to record the node identifier of the old version constraint decision node replaced by this constraint decision node.

[0029] This implementation enables the decision memory to support version evolution and weight differentiation of constraint decisions, improving the flexibility and accuracy of risk quantification.

[0030] In one implementation, the decision memory includes a vector database, which includes semantic vector records corresponding to several constraint decisions. Matching the context code semantic features of the change node with the feature matching conditions associated with the constraint decisions in the decision memory to obtain the constraint decision matched by the change node includes: performing a similarity search on the context code semantic features of the change node within the semantic vector records of the vector database; and selecting the constraint decision corresponding to the semantic vector record that meets the preset similarity conditions as the constraint decision matched by the change node.

[0031] This implementation uses a vector database to perform semantic vector similarity retrieval, enabling the matching of constraint decisions to recall constraints that are semantically similar to the change node at the semantic level, thereby improving the hit rate of fuzzy architecture constraints.

[0032] In one implementation, the decision memory further includes a vector database, which includes semantic vector records; the constraint decision nodes in the graph database also include a vector record identifier field; wherein, the vector record identifier field is used to map to the corresponding semantic vector record in the vector database, and the semantic vector record is obtained based on the semantics of at least one of the constraint intent field, syntax tree trigger field, and node type label of the corresponding constraint decision node. Matching the context code semantic features corresponding to the change node with the feature matching conditions associated with the constraint decisions in the decision memory to obtain the constraint decisions matched by the change node includes: converting the context code semantic features of the change node into code semantic vectors, performing similarity retrieval in the semantic vector records of the vector database; and selecting the constraint decision nodes corresponding to the semantic vector records that meet the preset similarity conditions as the constraint decision nodes matched by the change node; the method further includes: merging and deduplicating the constraint decision nodes matched by the change node through the context code semantic features and the constraint decision nodes matched by the change node through the context syntax structure features, to obtain all the constraint decision nodes matched by the change node.

[0033] This implementation uses a hybrid storage of graph database and vector database and establishes a mapping through the vector record identifier field, enabling the deterministic matching at the syntax tree level and the fuzzy matching at the semantic level to complement each other, thus achieving synergy in multimodal feature matching.

[0034] As one implementation, the method further includes: constructing historical code change record nodes corresponding to the code change event, writing the historical code change record nodes back to the graph database, and establishing an association between the historical code change record nodes and the constraint decision nodes matched by each change node; wherein, the historical code change record node includes an event information field, or, the constraint decision nodes connected to the historical code change record node include the event information field; the event information field includes the node identifier of the historical code change record node, the historical code change timestamp, and the code fragment of the historical code change.

[0035] This implementation writes back historical code change record nodes to the graph database, enabling the decision memory to accumulate historical change trajectories, providing historical data support for subsequent risk assessment and compromise decision queries.

[0036] In one implementation, at least some constraint decision nodes in the graph database further include a risk control operation level field, which is used to indicate the risk control operation that is forcibly executed in the code review interface; the risk control operation further includes: in response to the existence of at least one constraint decision node whose risk control operation level is an event-level blocking level, blocking the approval operation for the code change event; in response to receiving architectural compromise background information related to the constraint decision node of the event-level blocking level, and the architectural compromise background information meeting the preset legality requirements, releasing the blocking of the approval operation, writing back the compromise decision containing the architectural compromise background information to the decision memory, and establishing the association between the compromise decision and the relevant constraint decision node.

[0037] This implementation enables risk control operations to be enforced based on the blocking level of the constraint decision itself, thereby improving the protection of critical architectural constraints.

[0038] As one implementation, the preset legality requirements include at least one of the following: the length of the explanatory text explaining the reasons for the architecture compromise background information meets a preset length threshold; the architecture compromise background information includes an identifier of the code change event; the architecture compromise background information includes an identifier of a high-risk change node; the architecture compromise background information includes an identifier of a relevant constraint decision node; and the architecture compromise background information includes validity period information.

[0039] This implementation provides a clear and quantifiable standard for verifying the legitimacy of architectural compromise background information, preventing reviewers from circumventing the block with perfunctory excuses.

[0040] In one implementation, the compromise decision or the compromise decision node includes at least the following fields: a code event change identifier field, used to indicate the code change event involved in the compromise decision; a constraint decision node identifier field, used to indicate the constraint decision that the compromise decision violates and circumvents; and a constraint decision context field, used to indicate the background of the architecture compromise decision; wherein the constraint decision context field includes at least one of the following: decision-maker information field, explanation of the architecture compromise reason, relevant code snippet, and compromise decision expiration time.

[0041] This implementation method enables compromise decisions to fully record the context of architectural compromises, ensuring the traceability and convergence of technical debt.

[0042] In one implementation, when the compromise decision node includes a compromise decision expiration time, the method further includes: in response to the expiration time of any compromise decision node, triggering a code repair alarm to prompt the relevant code to be repaired according to the compromise decision node and the constraint decision node associated with it; in response to the completion of code repair, constructing a corresponding code repair record node and establishing an association between the code repair record node and the compromise decision node.

[0043] This implementation method ensures that technical debt is not permanently left behind due to compromise, thus creating a closed-loop governance chain from compromise to repair.

[0044] In one implementation, when the compromise decision node includes a compromise decision expiration time, the risk control operation further includes: responding to the existence of at least one change node with a high-risk level, or responding to the existence of at least one constraint decision node hit by at least one change node having a risk control operation level of event-level blocking level, querying whether the relevant constraint decision node is associated with a historical compromise decision; if a historical compromise decision is found, determining whether the code change event matches the compromise background information of the historical compromise decision; if they match, not blocking the approval operation for the code change event; if no historical compromise decision is found, or it is determined that the code change event does not match the compromise background information of the historical compromise decision, blocking the approval operation and waiting to receive the architecture compromise background information provided for the code change event.

[0045] This implementation method enables the automatic identification and protection of duplicate architectural compromises with the same background from repeated blocking, improving review efficiency while ensuring the traceability of compromises.

[0046] As one implementation, after obtaining the constraint decision nodes hit by the change node, the method further includes: for the constraint decision nodes hit by the change node, querying the graph database for the code pattern nodes, historical code change record nodes, and compromise decision nodes connected to the constraint decision node; forming decision context information for the constraint decision node based on the query results, including: constraint decision node identifier, risk weight field, syntax tree query expression field, historical code change record information field, and compromise decision information field; forming the decision context information payload corresponding to the change node for each constraint decision node hit by the change node, used to determine the risk level and risk basis of the change node.

[0047] This implementation method ensures that the determination of risk levels is based not only on numerical data but also on rich contextual information, thereby improving the interpretability of the risk assessment.

[0048] As one implementation method, the risk level of the change node is determined based on the risk identification strategy associated with the constraint decision of the change node hit, including: obtaining at least one of the deterministic hit input parameters, topology degradation input parameters, and semantic violation input parameters corresponding to the change node; wherein, the deterministic hit input parameters are used to characterize the degree of violation of the canonical code architecture by the contextual syntactic structure features of the change node, the topology degradation input parameters are used to characterize the degree of increase in code architecture complexity caused by the change node, and the semantic violation input parameters are used to characterize the degree of violation of the canonical code architecture by the contextual code semantic features of the change node; the decision deviation degree of the change node is calculated based on at least one of the deterministic hit input parameters, the topology degradation input parameters, and the semantic violation input parameters, and the risk level of the change node is determined based on the decision deviation degree.

[0049] This implementation calculates the decision deviation by integrating three input parameters: deterministic hit, topology degradation, and semantic violation. It unifies hard rule violations, structural decay, and semantic betrayal into comparable scalar scores, providing a numerical basis for threshold-based routing of risk levels.

[0050] As one implementation method, obtaining the deterministic hit input parameters corresponding to the change node includes: calculating the deterministic hit input parameters corresponding to the change node based on the risk weights of one or more constraint decisions hit by the change node through contextual grammar structure features; wherein, the risk weight of each constraint decision hit by the change node through contextual grammar structure features is positively correlated with the deterministic hit input parameters corresponding to the change node.

[0051] This implementation allows the impact of deterministic hits to be weighted differently according to the importance of the constraint decision, improving the accuracy of risk scoring.

[0052] As one implementation method, the step of obtaining the deterministic hit input parameter corresponding to the change node further includes: if all constraint decisions matched by the change node are hit through context code semantic features, then the deterministic hit input parameter corresponding to the change node is set to 0.

[0053] This implementation method ensures that constraint decisions based on pure semantic matching are not misjudged as deterministic violations, thus avoiding inflated risk scores.

[0054] As one implementation method, the deterministic hit input parameter corresponding to the change node is calculated as follows: M_hard = Σ(H_i × W_i); where M_hard represents the deterministic hit input parameter corresponding to the change node, H_i represents whether the change node hits the i-th constraint decision through the context syntax structure feature, if so, H_i is 1, otherwise H_i is 0, and W_i represents the risk weight associated with the i-th constraint decision.

[0055] This implementation provides an explicit quantitative calculation method for deterministic hit input parameters, enabling the impact of deterministic hits to be calculated accurately.

[0056] As one implementation method, obtaining the topology degradation input parameters corresponding to the changed node includes: extracting a structural complexity numerical representation from the contextual syntactic structure features of the changed node, wherein the structural complexity numerical representation includes at least one of: cyclomatic complexity increment, syntax tree depth, maximum nesting depth, number of branches, number of conditional expressions, and number of loop structures; calculating the topology degradation input parameters corresponding to the changed node based on the structural complexity numerical representation; wherein the structural complexity numerical representation corresponding to the changed node is positively correlated with the topology degradation input parameters corresponding to the changed node.

[0057] This implementation method allows the degree of code structure decay to be quantified, providing a measurable metric for the growth of architectural complexity.

[0058] As one implementation, the topology degradation input parameter corresponding to the changed node is determined as follows: D_topo=max(0,ΔC)×log2(Depth+1); where D_topo represents the topology degradation input parameter, ΔC represents the cyclomatic complexity increment corresponding to the changed node, and Depth represents the syntax tree depth or maximum nesting depth corresponding to the changed node.

[0059] This implementation provides an explicit quantitative calculation method for topological degradation input parameters, enabling the impact of structural decay to be accurately calculated.

[0060] As one implementation method, obtaining the semantic violation input parameters corresponding to the change node includes: for each constraint decision hit by the change node, determining the semantic violation information to be judged for the combination of the change node and the constraint decision based on the semantic features of the context code of the change node and the semantic features included in the constraint decision; the semantic features included in the constraint decision include at least one of constraint intent, syntax tree trigger expression, and syntax tree query expression of the code pattern associated with the constraint decision; calling a large language model to analyze the semantic violation information to be judged for the combination of the change node and the constraint decision to obtain the semantic violation judgment result of the combination of the change node and the constraint decision; the semantic violation judgment result includes at least the semantic violation probability; and obtaining the semantic violation input parameters corresponding to the change node based on the semantic violation probability of the combination formed by the change node and each hit constraint decision.

[0061] This implementation method calls a large language model to analyze the semantic violation information to be judged, so that architectural violations at the deep business semantic level can be automatically identified, making up for the blind spot of pure syntax matching in semantic violations.

[0062] In one implementation, the semantic violation input parameters corresponding to the change node are obtained based on the semantic violation probability of the combination formed by the change node and each matched constraint decision. This includes: obtaining the semantic violation input parameters corresponding to the change node based on the semantic violation probability of the combination formed by the change node and each matched constraint decision, and based on the risk weight of each matched constraint decision of the change node. The semantic violation probability of the combination formed by the change node and each matched constraint decision is positively correlated with the semantic violation input parameters corresponding to the change node, and the risk weight of each matched constraint decision is positively correlated with the semantic violation input parameters corresponding to the change node.

[0063] This implementation allows the impact of semantic violations to be weighted differently according to the importance of the constraint decision, improving the accuracy of risk scoring.

[0064] As one implementation method, the semantic violation input parameter corresponding to the change node is calculated by the following formula: P_weighted=max(P_i×W_i); where P_weighted represents the semantic violation input parameter, P_i represents the semantic violation probability of the combination formed by the change node and the hit i-th constraint decision, and W_i represents the risk weight of the hit i-th constraint decision of the change node.

[0065] This implementation provides an explicit quantitative calculation method for semantic violation input parameters, enabling the impact of semantic violations to be accurately calculated.

[0066] As one implementation method, the semantic violation analysis results of the combination of the change node and the constraint decision are obtained by calling a large language model to analyze the semantic violation information to be determined. This includes: constructing a semantic violation analysis payload in a preset format based on the semantic violation information of the combination of the change node and the constraint decision; the semantic violation analysis payload includes a change node semantic field, a constraint decision semantic field, and a result filling field; the change node semantic field is used to fill in the context code semantic features of the change node; the constraint decision semantic field is used to fill in the semantic features included in the constraint decision; the semantic violation analysis payload is input to the large language model, and the large language model fills in the semantic violation analysis results in the result field defined by the semantic violation analysis payload; and the semantic violation analysis results are extracted from the filled semantic violation analysis payload.

[0067] This implementation improves the controllability and parsability of semantic violation analysis by constructing a semantic violation analysis payload in a pre-formatted format and inputting it into a large language model.

[0068] In one implementation, the result filling fields include a violation determination field, a semantic violation probability field, and a violation reason field; the violation determination field is used by the large language model to fill in the determination result of whether the combination formed by the change node and the constraint decision violates the constraint decision; the semantic violation probability field is used by the large language model to fill in the probability that the combination formed by the change node and the constraint decision violates the constraint decision; the violation reason field is used by the large language model to fill in the reason why the combination formed by the change node and the constraint decision is determined to violate the constraint decision.

[0069] This implementation method enables semantic violation analysis results to simultaneously provide qualitative judgment, quantitative probability, and qualitative cause, thereby improving the completeness of risk assessment.

[0070] As one implementation, the semantic violation analysis payload includes structured output constraints, which are used to limit the field types and required fields that the large language model fills in the result filling fields; wherein, the field types include at least one of Boolean type, numeric type and string type, and the required fields include at least a violation determination field, a semantic violation probability field and a violation reason field.

[0071] This implementation method gives the output of the large language model clear format constraints, improving the reliability and parsability of semantic violation analysis results.

[0072] As one implementation, before extracting the semantic violation analysis result from the filled semantic violation analysis payload, the method further includes: verifying whether the filled semantic violation analysis payload satisfies the structured output constraints; extracting the semantic violation analysis result from the filled semantic violation analysis payload includes: extracting the semantic violation analysis result from the filled semantic violation analysis payload if the filled semantic violation analysis payload satisfies the structured output constraints.

[0073] This implementation method enables the filtering of large language model outputs that do not conform to format constraints, thereby improving the reliability of semantic violation analysis results.

[0074] As one implementation method, calculating the decision deviation of the change node includes: configuring corresponding calculation coefficients for the deterministic hit input parameter, the topology degradation input parameter, and the semantic violation input parameter, respectively; wherein, the calculation coefficient corresponding to the deterministic hit input parameter is greater than the calculation coefficient corresponding to the semantic violation input parameter; the calculation coefficient corresponding to the semantic violation input parameter is greater than the calculation coefficient corresponding to the topology degradation input parameter; and calculating the decision deviation of the change node based on the deterministic hit input parameter, the topology degradation input parameter, the semantic violation input parameter, and the corresponding calculation coefficients.

[0075] This implementation method gives the highest weight to deterministic violations, which aligns with the principle of prioritizing hard rules in architectural governance.

[0076] As one implementation method, the decision deviation of the changed node is calculated as follows: S = α × M_hard + β × D_topo + γ × P_weighted; where S represents the decision deviation of the changed node, M_hard represents the deterministic hit input parameter corresponding to the changed node, D_topo represents the topology degradation input parameter corresponding to the changed node, P_weighted represents the semantic violation input parameter corresponding to the changed node, and α, β, and γ represent the calculation coefficients of the corresponding input parameters.

[0077] This implementation provides a clear quantitative calculation method for decision deviation, enabling the architectural risks of the three dimensions to be fairly weighted and uniformly measured.

[0078] As one implementation method, after calculating the decision deviation of the changed node, the method further includes: performing a scoring transformation process on the decision deviation to obtain a risk score for the changed node; wherein the scoring transformation process includes at least one of normalization processing, truncation processing, and interval mapping processing.

[0079] This implementation allows decision deviation to be converted into a risk score that is easy to compare with thresholds and display on the interface, thus improving the practicality of risk level determination.

[0080] As one implementation method, determining the risk level of the change node based on the decision deviation includes: determining the risk level of the change node based on the relationship between the risk score of the change node and a preset risk threshold; wherein, if the risk score of the change node is less than or equal to the preset risk threshold, the risk level is low risk; if the risk score of the change node is greater than the preset risk threshold, the risk level is medium risk or high risk; if the difference between the risk score of the change node and the preset risk threshold is greater than a preset difference, the risk level is high risk.

[0081] This implementation method provides a clear quantitative standard for determining the risk level, avoiding subjective judgment.

[0082] As one implementation, the risk control operation further includes at least one of the following: when the risk level of the change node is low risk, perform a collapse operation on the code area corresponding to the change node; or, when the risk level of the change node is medium risk, display a warning mark in the code area or line number sidebar corresponding to the change node.

[0083] This implementation method allows for differentiated visual cues for change nodes at different risk levels within the review interface, thereby improving review efficiency.

[0084] As one implementation, the risk control operation further includes: in response to the existence of at least one change node having a risk level of high risk, or in response to the risk control operation level of at least one constraint decision hit by at least one change node being an event-level blocking level, displaying a high-risk warning sub-interface near the code area corresponding to the change node; wherein, the high-risk warning sub-interface includes a risk basis display area and an architecture compromise background information input area.

[0085] This implementation method enables reviewers of high-risk changes to simultaneously understand the basis for the risk and provide reasons for compromise, thus improving the completeness of the review interaction.

[0086] As one implementation method, a high-risk warning sub-interface is displayed near the code area corresponding to the change node, including: inserting a view control of a preset height after the code line corresponding to the change node and before the next code line. The view control is used to visually warn the approval operation. The view control includes a risk basis display area and an architecture compromise background information input area.

[0087] This implementation visually blocks reviewers' rapid scrolling by inserting view controls between lines of code to display high-risk warnings, ensuring that critical architectural risks are not overlooked.

[0088] As one implementation method, the risk basis includes at least one of the following: node-side risk basis, including at least one of the following: code location, code snippet, contextual syntax structure features, contextual code semantic features, risk score, and risk level of the relevant change node; constraint-side risk basis, including at least one of the following: constraint intent, risk weight, risk control operation level, syntax tree trigger expression, and syntax tree query expression of the code pattern connected thereto; scoring contribution basis, including at least one of the following: deterministic hit input parameters, topology degradation input parameters, semantic violation input parameters, and decision deviation degree corresponding to the change node; semantic violation analysis basis, including at least one of the following: violation judgment result of the combination formed by the change node and the matched constraint decision, semantic violation probability, and violation reason text; historical decision basis, obtained by querying historical code change records associated with the relevant constraint decision in the decision memory; and compromise state basis, obtained by querying compromise decisions associated with the relevant constraint decision in the decision memory, wherein the compromise state basis includes existing architecture compromise background information.

[0089] This implementation allows reviewers to understand risks from multiple perspectives, including node-side, constraint-side, scoring contribution, semantic violations, historical decisions, and compromise status, thereby improving the interpretability of the risk basis.

[0090] As one implementation, in response to the high-risk sub-interface being closed and no architectural compromise background information meeting preset legality requirements being received through the high-risk sub-interface, the high-risk sub-interface is displayed again.

[0091] This implementation eliminates the possibility of reviewers overlooking fatal architectural risks at the interaction level, and mandates that any architectural degradation must leave a reason for compromise.

[0092] In addition, the present invention also provides a computer program product having at least one instruction stored thereon, wherein the at least one instruction, when executed by a processor, implements the method described above.

[0093] The above solution enables the software-based distribution and deployment of review methods by providing computer program products.

[0094] In addition, the present invention also provides a control system for code change approval, including one or more program modules, which are used to implement the method described above.

[0095] Furthermore, the present invention also provides a computer device, comprising: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed as described above.

[0096] In addition, the present invention provides a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method described above. Attached Figure Description

[0097] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0098] Figure 1 This is a schematic diagram of the overall process of the code change approval control method according to an embodiment of the present invention;

[0099] Figure 2 This is a schematic diagram of the internal pipeline of the AST feature extraction engine in an embodiment of the present invention;

[0100] Figure 3 This is a schematic diagram of the hybrid storage architecture of decision memory graph according to an embodiment of the present invention;

[0101] Figure 4 This is a schematic diagram of data fusion for the decision deviation metric engine in an embodiment of the present invention;

[0102] Figure 5 This is a schematic diagram of the GUI rendering and interaction state machine blocking closed loop according to an embodiment of the present invention;

[0103] Figure 6 This is a GUI rendering of a background information input control for architectural compromise inserted in a high-risk blocking scenario according to an embodiment of the present invention, where the code line spacing is widened and the background information is inserted.

[0104] Figure 7 This is a schematic diagram of the internal flow logic of the architectural compromise background information during a high-risk blocking scenario according to an embodiment of the present invention.

[0105] Figure 8 This is a runtime full-link sequence execution timing diagram of an embodiment of the present invention. Detailed Implementation

[0106] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention are described below in conjunction with embodiments. The described embodiments are some embodiments of this invention and do not constitute a limitation on the scope of protection; other embodiments obtained by those skilled in the art based on this invention without creative effort are all within the scope of protection of this invention. Unless otherwise defined, the technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art.

[0107] Example 1

[0108] like Figure 1 As shown in the figure, this embodiment provides a control method for code change approval.

[0109] Specifically, the decision memory bank serves as the data foundation for the method of this invention. Its pre-construction is based on the fact that the core judgment criteria for code review should not only be whether the code compiles, but also whether it violates historical architectural constraints and lessons learned. These constraint decisions originate from the historical experience of senior engineers or enterprise architectural specifications. By persisting them as structured data rather than relying on human short-term memory, the continuity of decision-making is ensured. The feature matching conditions associated with each constraint decision are used for automated feature matching and hit determination when code changes occur; while the associated risk identification strategy is used to quantify the degree to which the change deviates from architectural constraints after a hit, converting architectural risk into a machine-calcifiable value. For example, feature matching conditions can be deterministic trigger expressions based on syntax tree patterns or fuzzy search conditions based on semantic vectors; risk identification strategies can be deviation calculation formulas based on multi-dimensional parameter fusion.

[0110] After the decision memory bank is pre-built, the method in this embodiment proceeds to step S100: in response to a code change event, the code text related to the code change event is obtained, and a syntax tree is parsed based on the code text to determine one or more syntax tree nodes involved in the code change as change nodes.

[0111] Code change events are typically submitted as Pull Requests or Merge Requests. Traditional review mechanisms, based on text comparison algorithms like Git Diff, can only detect additions, deletions, and modifications at the string level, failing to distinguish between changes with substantial semantic impact and textual changes without such impact. This step introduces syntax tree parsing, directly locating nodes with structural variations at the abstract syntax tree level, penetrating textual changes without substantial semantic impact. For example, when a developer submits code with a newly added hard-coded if-else branch, the text Diff might show multiple lines of new content, while syntax tree parsing can identify a newly added IfStatement syntax tree node and extract it as a changed node.

[0112] Subsequently, the method of this embodiment proceeds to step S200: for each change node, extract the context syntax structure features and / or context code semantic features corresponding to the change node; match the context syntax structure features and / or context code semantic features corresponding to the change node with the feature matching conditions associated with the constraint decisions in the decision memory to obtain the constraint decisions hit by the change node.

[0113] Isolated change nodes lack business significance and require extraction of their contextual features for effective matching with constraint decisions in the decision memory. Contextual syntactic structure features focus on representing the code's structural topology and anti-patterns, such as cyclomatic complexity increments and hard-coded temporary mapping markers; contextual code semantic features focus on representing the code's business intent and identifier semantics, such as method signatures and business domain identifiers. Matching these two types of features with the decision memory essentially aligns the current code change intent with historically verified or rejected paths. The matching process may result in direct hits, such as the change node's syntactic structure triggering a constraint decision's syntax tree trigger expression; it may also result in indirect hits, such as the change code's semantic vector being highly similar to a constraint's intent vector. By merging and deduplicating constraint decisions, the system identifies all possible architectural constraints that the change node may have violated.

[0114] After a constraint decision is hit, the method in this embodiment proceeds to step S300: The risk level of the changed node is determined based on the risk identification strategy associated with the constraint decision hit by the changed node. The determination of the risk level is not a simple binary judgment, but a quantitative assessment based on the risk identification strategy. The risk identification strategy integrates multi-dimensional signals such as the risk weight of the hit constraint decision, the degree of topological degradation of the changed node itself, and the probability of deep semantic violations into a comparable scalar score, such as decision deviation. Based on the relationship between this score and a preset threshold, the changed node is classified into low-risk, medium-risk, or high-risk levels. This quantitative mechanism allows the reviewer's attention to be precisely routed to the changes that truly affect the architecture based on numerical criteria, rather than treating all changes indiscriminately.

[0115] Finally, the method in this embodiment proceeds to step S400: risk control operations are performed in the code review interface according to the risk level of each change node; wherein, the risk control operations include at least: in response to the existence of at least one change node with a high risk level, blocking the approval operation for the code change event; in response to receiving architectural compromise background information related to the constraint decision hit by the high-risk change node, and the architectural compromise background information meeting the preset legality requirements, lifting the block on the approval operation, writing back the compromise decision containing the architectural compromise background information to the decision memory, and establishing the association between the compromise decision and the relevant constraint decision. This step constructs a governance link from interface blocking to a closed-loop compromise data system. When a high-risk change node exists, the system directly blocks the approval operation, forcing reviewers to acknowledge the architectural risks. However, in actual business, sometimes, in order to urgently fix online faults, it is necessary to temporarily accept certain architectural degradations. Therefore, this invention designs a compromise write-back mechanism: the reviewer must input background information on the architectural compromise related to the constraint decision, such as the compromise reason and expiration time. This information must meet preset legality requirements; for example, the length of the reason text must exceed a preset threshold to prevent perfunctory responses, and it must include the expiration time to ensure that the technical debt can converge before the block can be lifted. Once the block is lifted, the system writes back the compromise decision containing the architectural compromise background information to the decision memory and establishes its association with the relevant constraint decision. This closed-loop design transforms the originally implicit, human-memory-dependent debt into explicit, machine-traceable structured data through behavior. In the future, when a compromise expires, the system can automatically trigger a reconstruction alarm to ensure that technical debt does not accumulate indefinitely, achieving a closed loop and traceability of decision governance.

[0116] Example 2

[0117] like Figure 2 As shown, based on step S100 of Embodiment 1, this embodiment elaborates on the specific algorithm logic for obtaining code text and determining change nodes based on syntax tree parsing.

[0118] Specifically, obtaining the code text related to the code change event includes: obtaining the code text of the file involved in the code change event before the change and the code text after the change. By simultaneously extracting the code text before and after the change, dual baseline data is provided for subsequent structured alignment at the abstract syntax tree level, enabling the system to accurately pinpoint the specific location where the code architecture has changed.

[0119] Syntax tree parsing based on the code text includes: performing syntax tree parsing on the code text before and after the change, respectively, to generate a syntax tree before the change and a syntax tree after the change. In this embodiment, a multi-language parser such as Tree-sitter is used to generate the syntax tree. In other embodiments, other compiler front-end tools with syntax parsing capabilities can also be used, as long as they can convert text code into a structured tree topology.

[0120] Identifying one or more syntax tree nodes involved in code changes as changed nodes includes: performing structured alignment on the original and modified syntax trees, generating a set of syntax tree editing operations, and determining the one or more syntax tree nodes based on the set of syntax tree editing operations. Specifically, performing structured alignment on the original and modified syntax trees and generating the set of syntax tree editing operations includes: determining the isomorphic mapping relationship between the original and modified syntax trees; for syntax tree nodes without an isomorphic mapping, generating at least one syntax tree editing operation among insertion, deletion, update, or move, resulting in the set of syntax tree editing operations. In particular, this embodiment introduces a tree edit distance algorithm to achieve structured alignment. This algorithm establishes an isomorphic mapping relationship between two syntax trees by calculating the similarity of node labels and the Dice coefficient of child nodes. New nodes that cannot find an isomorphic mapping in the old tree are considered nodes that have undergone structural changes, and the system will generate specific editing operations for them, such as Insert, Delete, Update, or Move. This mechanism transforms the traditional linear understanding of "which lines of text were changed" into a topological understanding of "what structural changes occurred in the syntax tree," laying the foundation for subsequent extraction of features with architectural impact.

[0121] Before determining the one or more change nodes based on the set of syntax tree editing operations, the method further includes: performing semantic noise filtering on the set of syntax tree editing operations, discarding syntax tree editing operations involving semantic noise. Syntax tree editing operations involving semantic noise include at least one of whitespace characters, comments, formatting, and renaming; syntax tree editing operations not involving semantic noise include at least one of control flow, business logic, state judgment, exception handling, call relationships, and architectural boundaries. Semantic noise filtering is a crucial step in establishing a defense against auditing inaccuracies. With the widespread adoption of AI-assisted programming, developers or AI tools can easily generate a large amount of risk-free boilerplate code or formatting adjustments, which also generate editing operations at the syntax tree level. Without noise filtering, a large number of low-risk formatting changes and a small number of high-risk state judgment changes will be mixed in the same set, diluting the input signal to the downstream risk quantification engine and overwhelming the reviewer's attention with low-value noise. By discarding semantic noise such as whitespace characters and comments, the system ensures that only structural variations that truly affect control flow, business logic, or architectural boundaries can enter the subsequent risk calculation pipeline.

[0122] After filtering out semantic noise and identifying the true change node, this embodiment proceeds to the feature extraction stage. Extracting the contextual grammatical structure features and / or contextual code semantic features corresponding to the change node includes: taking the change node as the processing object, obtaining the node's basic information, host context information, and local context information. The node's basic information includes the change operation type and node type; the host context information is used to characterize the change node's parent grammatical structure in the syntax tree; and the local context information is used to characterize the change node itself and the local grammatical structure and local code content in its subtrees. Based on the node's basic information, the host context information, and the local context information, the contextual grammatical structure features and / or contextual code semantic features corresponding to the change node are generated.

[0123] Obtaining the host context information includes: traversing upwards along the parent node pointer from the changed node until the root node of the syntax tree is reached or a preset stopping condition is met, and extracting at least one of the following during the traversal: file path, package name, class name, function name, method signature, control block type, call path, and exception handling structure. The significance of upward traversal lies in tracing the host signature of the change. For example, a newly added IfStatement node, if its host context is the processPayment method of the core payment gateway, will have a different risk weight than if its host is a regular log printing utility method. Through upward traversal, the system anchors the macroscopic business domain and architectural location for micro-level code changes.

[0124] Obtaining the local context information includes: traversing the subtree starting from the changed node, and extracting at least one of the following: child node type, conditional expression structure, branch structure, loop structure, call expression structure, return statement structure, literal node type, maximum nesting depth, and syntax tree depth. The significance of downward traversal lies in revealing the local structural features of the change. For example, by traversing the subtree downwards, the system can calculate how many levels of nesting depth or how many branch structures the change introduced, thereby providing raw numerical parameters for subsequent quantification of topology degradation.

[0125] Building upon the aforementioned context extraction mechanism, this embodiment further refines the feature extraction dimensions. Extracting the contextual syntactic structure features corresponding to the change node includes: extracting the contextual syntactic structure features corresponding to the change node based on at least one of the following: change operation type, node type, parent node type, child node type, file path, class name, method signature, control block type, call path, exception handling structure, syntax tree depth, maximum nesting depth, number of conditional expressions, number of branches, number of loop structures, cyclomatic complexity increment, literal node type, and matched anti-pattern markers. The anti-pattern markers include hard-coded temporary mapping markers or unbounded enumeration markers; the unbounded enumeration markers are at least used to characterize the syntax tree structure in a switch statement where string literals are used as branch matching values; the hard-coded temporary mapping markers are at least used to characterize the syntax tree structure in an if statement where string literals are used as comparison objects. The anti-pattern markers are a static pre-detection mechanism implanted at the syntax tree level in this invention. AI programming assistants are prone to generating partially correct code that violates architectural constraints. For example, to quickly integrate new payment channels, they might directly pile up `else if` branches to match string literals without using polymorphic abstraction. This hard-coded temporary mapping is represented in the syntax tree as the `binary_expression` node of an `if` statement suspending comparison objects for string literals; unbounded enumerations are represented as a large number of string literals appearing in the `switch_case` node of a `switch` statement. The system directly captures these syntax tree representations through a pre-defined syntax tree query expression and marks them with anti-pattern tags. This design can identify architectural violations that impair scalability at the structural level without relying on time-consuming semantic reasoning, providing a deterministic basis for downstream risk quantification.

[0126] Extracting the contextual code semantic features corresponding to the change node includes: extracting the contextual code semantic features of the change node based on at least one of the following: code snippets, file paths, package names, class names, method signatures, variable identifiers, state variable identifiers, function call identifiers, calling object identifiers, literal values, conditional judgment semantics, return statement semantics, exception handling semantics, business domain identifiers, and anti-pattern markers. Unlike syntactic structure features, which focus on topology and patterns, code semantic features focus on extracting the business intent and identifier meanings of the code. This semantic information will be converted into vectors for fuzzy similarity retrieval in the decision memory, thereby recalling deep business constraints that cannot be captured by deterministic syntactic rules.

[0127] To structurally solidify and transfer the extracted multidimensional features, this embodiment further includes: generating a structured information payload to characterize the code change event; wherein the structured information payload includes at least one or more change node items, and each change node item includes one or more fields for recording the contextual syntax structure features and / or contextual code semantic features corresponding to the change node. This structured information payload is the input benchmark data provided by the syntax tree feature extraction engine to the downstream decision deviation measurement engine, which packages the originally messy Git text differences into a highly structured data object.

[0128] Each change node item includes at least the following fields: node identifier field, change operation type field, node type field, code snippet field, context information field, and structure information field. The context information field includes at least one of the following: class name field, method signature field, and syntax tree depth field. The structure information field includes at least one of the following: cyclomatic complexity increment field, static anti-pattern hit label field, and literal field. Through this field design, the system ensures that the downstream quantization engine, when calculating risk, can read the topological location of the change, such as the syntax tree depth, its structural complexity, such as the cyclomatic complexity increment, and directly obtain deterministic hit signals, such as static anti-pattern hit labels.

[0129] The structured information payload also includes a basic code change information item; this basic information item includes a code change record identifier field and a path field for the code file involved in the code change. This basic information item provides the payload with a globally unique identifier and tracing path, ensuring that when subsequently writing back compromise decisions or historical change records in the decision memory, the current code change event can be accurately linked.

[0130] This section provides a concrete example of a structured information payload (JSON Payload) to demonstrate how AST change nodes are encapsulated as structured features; in the following example, the comments on the right side of each line explain the meaning of the corresponding fields:

[0131] / / Start of structured loads

[0132] "change_id": "commit_8a7b6c_file_payment_ts", / / Change record ID

[0133] "file_path": "src / domain / payment / PaymentGateway.ts", / / Change the file path

[0134] "ast_changes": [ / / List of AST changed nodes]

[0135] { / / Single AST change node

[0136] "operation_type": "Insert", / / Edit operation type

[0137] "node_type": "IfStatement", / / Node type

[0138] "code_snippet": "if (gateway_type === 'NEW_CRYPTO') { ...}", / / Code snippet

[0139] "context": { / / Node context

[0140] "class_name": "PaymentProcessor", / / Class name

[0141] "method_signature": "public async processPayment(...)", / / Method signature

[0142] "depth_in_tree": 5 / / Syntax tree depth

[0143] }, / / End of node context

[0144] "structural_features": { / / Structural features

[0145] "cyclomatic_complexity_increment": 1, / / Cyclomatic complexity increment

[0146] "static_anti_patterns_detected": [ / / List of antipatterns]

[0147] "anti_pattern.hardcoded_if_mapping" / / Hardcoded if mapping flag

[0148] ], / / End of anti-pattern list

[0149] "extracted_literals": ["NEW_CRYPTO"] / / Extracted literals

[0150] / / End of structural features

[0151] / / End of single AST change node

[0152] / / End of AST change node list

[0153] / / End of structured load

[0154] Example 3

[0155] like Figure 3 As shown, based on step S200 of Embodiment 1, this embodiment elaborates on the underlying architecture and matching retrieval logic of the decision memory bank.

[0156] Specifically, the decision memory includes a graph database, which stores several constraint decision nodes and several code pattern nodes in a directed graph topology. The graph database is introduced to address the pain point of fragmented decision context data in traditional review mechanisms. Traditional knowledge bases typically store architectural constraints using flat text or relational tables, failing to express the evolutionary replacement relationships or triggering dependencies between constraints. This embodiment, through a directed graph topology, transforms architectural decisions into graph nodes and relational edges with lineage paths, enabling the system not only to query what constraints are currently present but also to trace which old constraints each constraint replaces and which code patterns historically triggered that constraint.

[0157] Each constraint decision node includes at least a constraint intent field and a syntax tree trigger field, wherein the syntax tree trigger field includes a syntax tree trigger expression. The constraint intent field records the business purpose of the constraint in natural language, such as "prohibit unbounded enumeration of payment gateways"; the syntax tree trigger field stores deterministic trigger expressions based on syntaxes such as Tree-sitterQuery, for example, query expressions that match hard-coded if-else branches. This dual-field design provides the downstream risk quantification engine with both a semantic reasoning input benchmark and a deterministic hit determination criterion.

[0158] Each code pattern node includes at least a syntax tree query field, which contains a syntax tree query expression. The code pattern node is an abstract extraction of common anti-patterns or architectural violation patterns. Its syntax tree query field stores the query expression used for pattern matching at the syntax tree level. The existence of code pattern nodes establishes an intermediate layer: not all architectural constraints require directly writing extremely complex syntax tree trigger expressions; common destructive code patterns can be abstracted into independent code pattern nodes and bound to constraint decision nodes through relational edges.

[0159] Each code pattern node is connected to at least some constraint decision nodes via directed triggering edges. This indicates that when a code pattern node is directly matched, the corresponding constraint decision node is indirectly matched along the directed triggering edges. This design of directed triggering edges decouples and maps code features to architectural intent. For example, when a developer's code hits the code pattern node "hard-coded temporary mapping," the system can indirectly pinpoint the underlying constraint decision node that is actually violated, "prohibit unbounded enumeration of gateways," by traversing the directed triggering edges. This mechanism allows constraint decision nodes to cover multiple variations without exhaustively enumerating all possible code behaviors, simply by associating with code pattern nodes, thus improving the system's scalability and hit rate.

[0160] The constraint decision nodes in the graph database further include at least one of a node identifier field, a node version number field, and a node type label field; or the constraint decision nodes in the graph database further include at least one of a risk weight and a risk control operation level; or the constraint decision nodes in the graph database further include a replacement relationship field, used to record the node identifier of the old constraint decision node replaced by this constraint decision node. The replacement relationship field is crucial for constructing the decision evolution lineage. In real software evolution, architectural constraints are not static; old constraints are often replaced by new ones. By recording the old node identifier, the replacement relationship field allows the system to trace its evolution history along the graph topology when the current constraint is hit, providing reviewers with a more complete decision context. The risk weight and risk control operation level fields provide direct numerical and strategy parameters for downstream risk quantification and interface blocking.

[0161] Based on the aforementioned graph database architecture, the matching logic in this embodiment is divided into two complementary paths. Path one is deterministic matching based on contextual syntax structure features: the contextual syntax structure features corresponding to the change node are matched with the syntax tree trigger field of the constraint decision node in the graph database to obtain a directly matched constraint decision node; the contextual syntax structure features corresponding to the change node are matched with the syntax tree query field of the code pattern node in the graph database to obtain an indirectly matched constraint decision node; the directly matched constraint decision and the indirectly matched constraint decision are merged and deduplicated to obtain the constraint decision node that the change node has hit. This path addresses the problem of intercepting explicit schema violations. For example, when the anti-pattern marker extracted from the change node hits the query expression of the code pattern node, the system indirectly finds the constraint decision node through directed triggering relationship edges; simultaneously, if the syntax structure of the change node directly triggers the syntax tree trigger expression of the constraint decision node itself, a direct hit occurs. The merging and deduplication operations ensure that the same constraint is not repeatedly calculated for risk weight.

[0162] Path two involves fuzzy retrieval based on contextual code semantic features: the decision memory includes a vector database containing semantic vector records corresponding to several constraint decisions; the contextual code semantic features of the change node are used to perform a similarity search on the semantic vector records in the vector database; the constraint decisions corresponding to the semantic vector records that meet preset similarity conditions are taken as the constraint decisions matched by the change node. This path addresses the recall problem of deep business constraints. Many deep architectural constraints cannot be captured using deterministic syntax tree trigger expressions because their violations are diverse and subtle. By performing searches such as cosine similarity between the code semantic features of the change node and the semantic vector records of the constraint decisions, the system can recall constraint decisions that are highly similar in business intent but lack obvious characteristics in code structure.

[0163] To achieve collaboration between the two paths, the decision memory also includes a vector database containing semantic vector records. The constraint decision nodes in the graph database also include a vector record identifier field. This vector record identifier field maps to the corresponding semantic vector record in the vector database. This semantic vector record is obtained based on at least one of the constraint intent field, syntax tree trigger field, and node type label of the corresponding constraint decision node. The vector record identifier field serves as a foreign key mapping for the collaboration between the two databases. The vector database itself does not store the complete business context; it only indexes and retrieves high-dimensional semantic vectors. Once a semantic vector record matching the similarity criteria is retrieved, the system uses the vector record identifier field to map back to the corresponding constraint decision node in the graph database, thereby obtaining the node's complete topological relationship, risk weight, and historical trial-and-error trajectory. This decoupled dual-database design leverages the efficient retrieval capabilities of the vector database in a massive semantic space while retaining the advantages of the graph database in complex relationship traversal and lineage tracing.

[0164] During the execution of path two, the contextual code semantic features of the change node are converted into code semantic vectors, and similarity is searched in the semantic vector records of the vector database. The constraint decision nodes corresponding to the semantic vector records that meet the preset similarity conditions are taken as the constraint decision nodes matched by the change node. The method also includes merging and deduplicating the constraint decision nodes matched by the change node through contextual code semantic features and the constraint decision nodes matched by the change node through contextual syntax structure features, and taking them as all the constraint decision nodes matched by the change node. Among them, this merging and deduplication operation is the core of establishing complementary matching. Although deterministic syntax tree matching is accurate, it can only intercept known, structured explicit anti-patterns, and has blind spots for variant forms or deep intents; while semantic vector retrieval can recall deep intents, there is a possibility of false recall. Merging and deduplicating the two means that as long as the change node touches the architectural constraints on any path, the system can capture it, thereby improving the coverage of complex architectural constraints and realizing the complementarity of multimodal feature matching.

[0165] After matching is completed, this embodiment further includes constructing historical code change record nodes corresponding to the code change event, writing the historical code change record nodes back to the graph database, and establishing the association between the historical code change record nodes and the constraint decision nodes hit by each change node. The historical code change record nodes include an event information field, or the constraint decision nodes connected to the historical code change record nodes include the event information field. The event information field includes the node identifier of the historical code change record node, the historical code change timestamp, and the code fragment of the historical code change. This write-back mechanism transforms the originally one-time code review behavior into structured data that can be accumulated and traced. When a future code change hits the same constraint decision node again, the system can traverse the historical code change record nodes connected to that constraint decision node to show the reviewer which code changes have violated the constraint in the past, thereby providing decision context. The code fragments and timestamps in the event information field ensure the traceability of decision lineage, enabling the system not only to know what constraint was violated, but also to reconstruct when and in what code form it was violated historically.

[0166] Example 4

[0167] like Figure 4 As shown, based on step S300 of Embodiment 1, this embodiment elaborates on the specific quantitative algorithm for determining the risk level of the change node according to the risk identification strategy associated with the hit constraint decision.

[0168] Based on the risk identification strategy associated with the constraint decision of the change node, the risk level of the change node is determined, including: obtaining at least one of the deterministic hit input parameters, topology degradation input parameters, and semantic violation input parameters corresponding to the change node. The deterministic hit input parameters characterize the degree to which the contextual syntactic structure features of the change node violate the standard code architecture; the topology degradation input parameters characterize the degree to which the change node increases the complexity of the code architecture; and the semantic violation input parameters characterize the degree to which the contextual code semantic features of the change node violate the standard code architecture. These three input parameters constitute the three dimensions of the quantitative architecture deviation of this invention: the deterministic hit parameter captures explicit, known pre-detection rule violations; the topology degradation parameter captures the degradation and complexity trends at the code structure level; and the semantic violation parameter captures deep-seated business intent deviations. Based on at least one of the deterministic hit input parameters, the topology degradation input parameters, and the semantic violation input parameters corresponding to the change node, the decision deviation degree of the change node is calculated, and the risk level of the change node is determined based on the decision deviation degree.

[0169] First, the deterministic hit input parameters corresponding to the change node are obtained, including: calculating the deterministic hit input parameters corresponding to the change node based on the risk weights of one or more constraint decisions hit by the change node through contextual grammatical structure features. The risk weight of each constraint decision hit by the change node through contextual grammatical structure features is positively correlated with the deterministic hit input parameters corresponding to the change node. Specifically, the deterministic hit input parameters corresponding to the change node are calculated as follows: M_hard = Σ(H_i × W_i); where M_hard represents the deterministic hit input parameters corresponding to the change node, H_i indicates whether the change node hits the i-th constraint decision through contextual grammatical structure features (if yes, H_i is 1; otherwise, H_i is 0), and W_i represents the risk weight associated with the i-th constraint decision. Wherein, as long as the grammatical structure features of the change node trigger the preset pre-examination expression in the decision memory, it is considered a deterministic architectural violation, and the risk weight of the constraint decision is directly accumulated as a hard penalty term. For example, if the changed node hits the "prohibit gateway unbounded enumeration" constraint with a risk weight of 4.8, then M_hard will be at least 4.8.

[0170] However, the step of obtaining the deterministic hit input parameter corresponding to the change node also includes: if all constraint decisions matched by the change node are hits through context code semantic features, then the deterministic hit input parameter corresponding to the change node is set to 0. This setting to 0 logic is a key step in the numerical priority established in this invention, and its purpose is to prevent circumvention. Why can't pure semantic hits contribute to deterministic penalties? Because semantic vector retrieval is essentially a fuzzy similarity recall, which may result in false recalls or semantic drift. If pure semantic hits are allowed to contribute hard penalty weights, developers may change the code semantic vector by fine-tuning variable names or adding harmless comments, thereby circumventing hard rule interception. Setting M_hard of pure semantic hits to 0 means that the system clearly distinguishes between "deterministic red line violations" and "suspected intent similarity." The former has a veto power, while the latter needs to be softly evaluated by subsequent semantic violation probability inference terms, thereby preventing vulnerabilities in circumventing architectural constraints through semantic masquerading.

[0171] Secondly, the topology degradation input parameters corresponding to the changed node are obtained, including: extracting a numerical representation of structural complexity from the contextual syntax features of the changed node. This numerical representation of structural complexity includes at least one of the following: cyclomatic complexity increment, syntax tree depth, maximum nesting depth, number of branches, number of conditional expressions, and number of loop structures. Based on the numerical representation of structural complexity corresponding to the changed node, the topology degradation input parameters corresponding to the changed node are calculated; wherein, the numerical representation of structural complexity corresponding to the changed node is positively correlated with the topology degradation input parameters corresponding to the changed node. Specifically, the topology degradation input parameters corresponding to the changed node are determined as follows: D_topo = max(0, ΔC) × log2(Depth + 1); where D_topo represents the topology degradation input parameters, ΔC represents the cyclomatic complexity increment corresponding to the changed node, and Depth represents the syntax tree depth or maximum nesting depth corresponding to the changed node. The design consideration of this formula is that the cyclomatic complexity increment ΔC represents the increase in the number of independent execution paths introduced by the change, which is a direct measure of code complexity; while log2(Depth + 1) introduces a logarithmic penalty effect on the nesting depth. For example, when ΔC=1 and Depth=3, D_topo=1×log2(4)=2.0; while when the developer builds a deep nested structure with ΔC=5 and Depth=6 to quickly integrate new logic, D_topo=5×log2(7)≈14, and the penalty term grows non-linearly. This design means that even if the large language model considers the code semantics to be correct, as long as the developer solves new requirements by building nested if-else statements, the topology degradation term will increase the decision deviation, thereby identifying architectural violations that impair scalability.

[0172] Next, the key step is to obtain the semantic violation input parameters corresponding to the changed node. This process is achieved by introducing a large language model as a referee probe. Obtaining the semantic violation input parameters corresponding to the changed node includes: for each constraint decision hit by the changed node, determining the semantic violation information to be judged for the combination of the changed node and the constraint decision based on the semantic features of the context code of the changed node and the semantic features included in the constraint decision. The semantic features included in the constraint decision include at least one of the following: constraint intent, syntax tree trigger expression, and syntax tree query expression of the code pattern associated with the constraint decision. The large language model is then used to analyze the semantic violation information to be judged for the combination of the changed node and the constraint decision, obtaining the semantic violation judgment result for the combination of the changed node and the constraint decision; the semantic violation judgment result includes at least the semantic violation probability. Based on the semantic violation probability of the combination formed by the changed node and each hit constraint decision, the semantic violation input parameters corresponding to the changed node are obtained.

[0173] To ensure the computability and prevent illusions in the output of the large language model, this embodiment designs a rigorous payload construction and verification logic. The large language model is invoked to analyze the semantic violation information to be determined in the combination of the changed node and the constraint decision, obtaining the semantic violation analysis result of the combination. This includes: constructing a semantic violation analysis payload in a preset format based on the semantic violation information to be determined in the combination of the changed node and the constraint decision; the semantic violation analysis payload includes a changed node semantic field, a constraint decision semantic field, and a result filling field; the changed node semantic field is used to fill in the context code semantic features of the changed node; the constraint decision semantic field is used to fill in the semantic features included in the constraint decision. The semantic violation analysis payload is input to the large language model, which fills in the semantic violation analysis result in the result field defined by the semantic violation analysis payload; the semantic violation analysis result is extracted from the filled semantic violation analysis payload.

[0174] Specifically, the result filling fields include a violation determination field, a semantic violation probability field, and a violation reason field. The violation determination field is used by the large language model to input the determination result of whether the combination formed by the changed node and the constraint decision violates the constraint decision. The semantic violation probability field is used by the large language model to input the probability that the combination formed by the changed node and the constraint decision violates the constraint decision. The violation reason field is used by the large language model to input the reason why the combination formed by the changed node and the constraint decision is determined to violate the constraint decision. The semantic violation analysis payload includes structured output constraints, which are used to limit the field types and required fields that the large language model fills in the result filling fields. The field types include at least one of Boolean, numeric, and string types, and the required fields include at least the violation determination field, the semantic violation probability field, and the violation reason field. The significance of this JSON Schema design is that the large language model is essentially a probability-based text generator. If it is not forced to fill in the results according to the preset fields and types through structured output constraints, the model is very likely to output lengthy natural language interpretations that cannot be parsed by downstream mathematical engines, or even produce illusions. By limiting the required fields and their types, the system transforms the large language model from a "free text generator" into a "callable structured referee probe," ensuring that the semantic violation probability P_i can be accurately extracted as a floating-point number, rather than a vague text description.

[0175] Furthermore, before extracting the semantic violation analysis result from the filled semantic violation analysis payload, the method further includes: verifying whether the filled semantic violation analysis payload satisfies the structured output constraints; extracting the semantic violation analysis result from the filled semantic violation analysis payload includes: extracting the semantic violation analysis result from the filled semantic violation analysis payload if the filled semantic violation analysis payload satisfies the structured output constraints. This verification logic is a defense against abnormal model output. If the model fails to fill in the required violation judgment field or probability field according to the constraints, the system will refuse to extract the result and trigger retry or degradation processing in some embodiments, thereby ensuring the reliability of the input parameters of the downstream fusion formula.

[0176] After extracting the semantic violation probability, the semantic violation input parameters corresponding to the change node are obtained based on the semantic violation probability of the combination formed by the change node and each matched constraint decision. These parameters include: the semantic violation probability of the combination formed by the change node and each matched constraint decision, and the risk weight of each matched constraint decision. Specifically, the semantic violation probability of the combination formed by the change node and each matched constraint decision is positively correlated with the semantic violation input parameters corresponding to the change node, and the risk weight of each matched constraint decision is also positively correlated with the semantic violation input parameters corresponding to the change node. The semantic violation input parameters corresponding to the change node are calculated using the following formula: P_weighted = max(P_i × W_i); where P_weighted represents the semantic violation input parameters, P_i represents the semantic violation probability of the combination formed by the change node and the i-th matched constraint decision, and W_i represents the risk weight of the i-th matched constraint decision. The design consideration for using a max function instead of an accumulation function is that the semantic violation probability itself is uncertain, and accumulating multiple uncertain probabilities would lead to bloated distortion of the penalty term. Taking the maximum value means that the system only adopts the violation judgment with the highest model confidence and the largest risk weight as the representative, thereby suppressing numerical noise caused by false recalls while retaining semantic interception capabilities.

[0177] After obtaining the calculation results of the above three dimensions in parallel, the decision deviation of the changed node is calculated, including: configuring corresponding calculation coefficients for the deterministic hit input parameter, the topology degradation input parameter, and the semantic violation input parameter, respectively; wherein, the calculation coefficient corresponding to the deterministic hit input parameter is greater than the calculation coefficient corresponding to the semantic violation input parameter; the calculation coefficient corresponding to the semantic violation input parameter is greater than the calculation coefficient corresponding to the topology degradation input parameter. Based on the deterministic hit input parameter, the topology degradation input parameter, the semantic violation input parameter, and the corresponding calculation coefficients, the decision deviation of the changed node is calculated. The decision deviation of the changed node is calculated as follows: S = α × M_hard + β × D_topo + γ × P_weighted; where S represents the decision deviation of the changed node, M_hard represents the deterministic hit input parameter corresponding to the changed node, D_topo represents the topology degradation input parameter corresponding to the changed node, P_weighted represents the semantic violation input parameter corresponding to the changed node, and α, β, and γ represent the calculation coefficients of the corresponding input parameters.

[0178] The constraint of coefficient setting (α>γ>β) is the core of establishing numerical priority in this invention. Why is the weight of hard rules greater than that of semantic rules? Because deterministic hits (M_hard) represent pre-detection rule touches that have been verified by historical lessons (such as deadlocks and memory leaks), and have veto power. They must be given the highest coefficient α (e.g., 2.0) to ensure that their interception priority is not diluted by low scores in other dimensions. Although semantic violations (P_weighted) can capture deep intent, their coefficient γ (e.g., 1.5) must be lower than α due to the uncertainty of model confidence, to prevent the model from misjudging and causing false positives. Topology degradation (D_topo) reflects the gradual degradation of the code structure. Its effects are often long-term and implicit, and do not immediately constitute a high risk. Therefore, its coefficient β (e.g., 0.5) is the lowest, serving as an auxiliary penalty. This tiered coefficient constraint ensures that the system can make priority routing that conforms to engineering intuition when faced with architectural deviations of different natures.

[0179] After calculating the decision deviation of the changed node, the process further includes: performing a score transformation process on the decision deviation to obtain a risk score for the changed node; wherein the score transformation process includes at least one of normalization, truncation, and interval mapping. Since the calculation result of the fusion formula may exceed the numerical range acceptable to the front-end rendering engine, the score transformation process is a necessary numerical boundary constraint. For example, truncation can truncate extreme deviations exceeding 10.0 to 10.0, thereby providing a stable numerical domain for subsequent threshold routing.

[0180] Finally, the risk level of the changed node is determined based on the decision deviation, including: determining the risk level of the changed node based on the relationship between the risk score of the changed node and a preset risk threshold. Specifically, if the risk score of the changed node is less than or equal to the preset risk threshold, the risk level is low risk; if the risk score of the changed node is greater than the preset risk threshold, the risk level is medium or high risk; if the difference between the risk score of the changed node and the preset risk threshold is greater than a preset difference, the risk level is high risk. This two-layer routing logic based on a preset risk threshold and the difference achieves refined risk level classification. For example, the preset risk threshold is set to 2.0, and the preset difference is 2.0. When S_drift=1.5, it falls under the low-risk level, and the system will perform a collapse operation to draw the reviewer's attention. When S_drift=3.5, it exceeds the threshold but the difference is less than 2.0, falling under the medium-risk level, and the system will display a warning flag. When S_drift=10.0, it exceeds the threshold and the difference is far greater than 2.0, falling under the high-risk level, and the system will forcibly block the approval operation and require architectural compromise. It should be understood that although this embodiment lists specific thresholds and difference values, in other embodiments, these values ​​can be dynamically adjusted according to the strictness of the enterprise's architectural specifications or the project's lifecycle stage, as long as the functional requirement of risk routing based on numerical criteria is met.

[0181] Example 5

[0182] like Figure 5 As shown, based on step S400 of Embodiment 1, this embodiment elaborates in detail on the specific GUI implementation and interactive state machine closed-loop logic of the risk control operation performed in the code review interface according to the risk level. It should be understood that the interface rendering mechanism described in this embodiment is only illustrative and not restrictive, and is intended to illustrate how to transform abstract risk quantification values ​​into interactive constraints, rather than limiting the present invention to be implemented only based on a specific front-end editor API.

[0183] First, the risk control operation also includes at least one of the following: when the risk level of the change node is low, perform a collapse operation on the code area corresponding to the change node; or, when the risk level of the change node is medium, display a warning mark in the code area or line number sidebar corresponding to the change node. Specifically, the low-risk collapse operation and the medium-risk warning mark are the first line of defense for optimizing the reviewer's cognitive load in this invention. In the current era of widespread AI-assisted programming, a single code change may contain hundreds of lines of low-risk boilerplate code and a very small number of high-risk state machine breaking codes. If reviewers are required to read through each line, it will lead to severe cognitive overload and the review will become a mere formality. This embodiment intercepts the view rendering layer of the front-end editor. When the decision deviation is lower than a preset risk threshold, it directly calls the editor's hidden area API to collapse the DOM node corresponding to the boilerplate code, freeing up the reviewer's visual attention; when the decision deviation is in the medium range, it does not interfere with the code reading flow, but only hangs a clickable warning pin in the line number sidebar to prompt the reviewer to pay attention. The technical effect of this layered rendering mechanism is that it realizes the transformation of the interaction paradigm from comprehensive inspection to intelligent sampling inspection based on risk nodes.

[0184] However, for high-risk change nodes, simple warning flags are insufficient to prevent architectural degradation. The risk control operation further includes: in response to the existence of at least one change node with a high-risk level, or in response to at least one constraint decision triggered by at least one change node, the risk control operation level is set to an event-level blocking level, displaying a high-risk warning sub-interface near the code area corresponding to the change node; wherein the high-risk warning sub-interface includes a risk basis display area and an architectural compromise background information input area. This introduction of an event-level blocking level represents an advanced defense against the high-risk blocking logic in Example 1. At least some constraint decision nodes in the graph database also include a risk control operation level field, which indicates the risk control operation that is forcibly executed in the code review interface. The risk control operation further includes: in response to the existence of at least one constraint decision node hit by at least one change node having an event-level blocking level for the risk control operation level, blocking the approval operation for the code change event; in response to receiving architectural compromise background information related to the constraint decision node at the event-level blocking level, and the architectural compromise background information meeting preset legality requirements, removing the blocking of the approval operation, writing back the compromise decision containing the architectural compromise background information to the decision memory, and establishing the association between the compromise decision and the relevant constraint decision node. The design consideration of the event-level blocking level is that some architectural constraints (such as the security boundary of the payment gateway) have a system-critical level of pre-detection importance. Even if the decision deviation value of the current change node does not reach the high-risk threshold due to the lack of certain dimensions, as long as it touches the trigger expression of such constraints, the system must forcibly block the entire approval process at the event level, rather than just displaying a warning at the node level. This design establishes a layer of defense depth, ensuring the veto power of hard rules.

[0185] A high-risk warning sub-interface is displayed near the code area corresponding to the change node. This includes inserting a view control of preset height after the code line corresponding to the change node and before the next code line. The view control is used to visually warn of the approval operation. The view control includes a risk basis display area and an input area for architectural compromise background information. This GUI implementation is the core mechanism that distinguishes this invention from traditional read-only code review. Traditional warning prompts usually use Toast pop-ups or inline highlighting, which reviewers can easily ignore by quickly scrolling. This embodiment uses the Zone Widget technology of the underlying compiler to insert a space between code lines. Specifically, the system instantiates the editor's IViewZone interface, forcibly modifies the heightInPx parameter of afterLineNumber to increase the page height, and dynamically renders an independent decision card component in this DOM node. The technical effect of this view control insertion method is that it makes it impossible for reviewers to ignore architectural risks through visual inertia, forcing reviewers to look at the decision card and make an explicit choice.

[0186] To support the information display in the decision card, the risk basis includes at least one of the following: node-side risk basis, including at least one of the following: code location, code snippet, contextual syntax structure features, contextual code semantic features, risk score, and risk level of the relevant change node; constraint-side risk basis, including at least one of the following: constraint intent, risk weight, risk control operation level, syntax tree trigger expression, and syntax tree query expression of the code pattern connected to it; scoring contribution basis, including at least one of the following: deterministic hit input parameters, topology degradation input parameters, semantic violation input parameters, and decision deviation degree corresponding to the change node; semantic violation analysis basis, including at least one of the following: violation judgment result of the combination formed by the change node and the matched constraint decision, semantic violation probability, and violation reason text; historical decision basis, obtained by querying historical code change records associated with relevant constraint decisions in the decision memory; and compromise status basis, obtained by querying compromise decisions associated with relevant constraint decisions in the decision memory, wherein the compromise status basis includes background information on existing architecture compromises. This multi-dimensional risk basis display breaks down the data gaps in the decision context of traditional review interfaces. Reviewers can see not only what has changed in the code, but also why it changed, what historical constraints were violated, what failures it caused in the past, and whether there have been any temporary compromises. This context-penetration mechanism transforms implicit judgments that previously relied on the short-term memory of senior engineers into structured audit trails that can be explicitly injected into the machine.

[0187] After presenting the risk basis, the system requires the reviewer to input background information on the architectural compromise to remove the block. The preset legality requirements include at least one of the following: the length of the explanatory text for the architectural compromise background information meets a preset length threshold; the architectural compromise background information includes an identifier of the code change event; the architectural compromise background information includes identifiers of high-risk change nodes; the architectural compromise background information includes identifiers of relevant constraint decision nodes; and the architectural compromise background information includes validity period information. The legality requirements are designed to prevent perfunctory compromises. For example, requiring the explanatory text to exceed 20 characters forces the reviewer to deeply consider the long-term impact of technical debt; requiring validity period information ensures that technical debt has a time boundary and does not accumulate indefinitely. Only when these legality requirements are met will the system allow the state machine to transition to the debt-based approval state.

[0188] Once the reviewer inputs valid background information on architectural compromises, the system constructs a compromise decision node and writes it back to the decision memory. The compromise decision or the compromise decision node includes at least the following fields: a code event change identifier field, indicating the code change event involved in the compromise decision; a constraint decision node identifier field, indicating the constraint decision violated and circumvented by the compromise decision; and a constraint decision context field, indicating the background of the architectural compromise decision. The constraint decision context field includes at least one of the following: decision-maker information, explanation of the architectural compromise reason, relevant code snippets, and the expiration time of the compromise decision. This structured field design provides a data foundation for closed-loop governance of technical debt. The compromise decision node is not a one-time exemption record, but rather establishes a connection with the constraint decision node, becoming a permanent topological node in the decision memory graph.

[0189] Based on this association, when the compromise decision node includes a compromise decision expiration time, the method further includes: in response to the expiration time of any compromise decision node, triggering a code repair alert to prompt the developer to repair the relevant code based on the compromise decision node and its associated constraint decision node; in response to the completion of code repair, constructing a corresponding code repair record node and establishing an association between the code repair record node and the compromise decision node. This closed-loop mechanism of expiration alerts and repair records is key to achieving convergent technical debt in this invention. When the expiration time of temporary hard-coded code arrives, the system automatically triggers a refactoring alert, prompting the developer to repair according to the context of the compromise decision and constraint decision. After the repair is completed, a code repair record node is constructed and associated with the compromise decision node, marking the settlement of technical debt. This design ensures that architectural degradation is not forgotten over time, achieving a closed loop and traceability of decision governance.

[0190] Furthermore, when the compromise decision node includes a compromise decision expiration time, the risk control operation further includes: responding to the existence of at least one change node with a high-risk level, or responding to the existence of at least one constraint decision node hit by at least one change node having an event-level blocking level in the risk control operation, querying whether the relevant constraint decision node is associated with a historical compromise decision; if a historical compromise decision is found, determining whether the code change event matches the compromise background information of the historical compromise decision; if they match, not blocking the approval operation for the code change event; if no historical compromise decision is found, or it is determined that the code change event does not match the compromise background information of the historical compromise decision, blocking the approval operation and waiting to receive the architecture compromise background information provided for the code change event. This historical compromise decision matching exemption logic is the core of the non-one-size-fits-all blocking defense depth of this invention. Why not a one-size-fits-all blocking? Because in real business evolution, certain architectural degradations are consciously accepted within a specific time window. If every time the same constraint is touched, it is forced to re-enter the compromise reason, it will seriously interfere with the emergency release process. By querying historical compromise decisions associated with constraint decision nodes and determining whether the context of the current change event matches historical compromises, the system allows for reuse of exemptions within the same business context. This design ensures that architectural constraints are not silently circumvented while also considering engineering efficiency, achieving precise dynamic governance.

[0191] To support the presentation of the aforementioned risk control operations and risk basis, after obtaining the constraint decision nodes hit by the change node, the method further includes: querying the graph database for the constraint decision nodes hit by the change node, including the code pattern nodes, historical code change record nodes, and compromise decision nodes connected to the constraint decision node; forming the decision context information of the constraint decision node based on the query results, including: constraint decision node identifier, risk weight field, syntax tree query expression field, historical code change record information field, and compromise decision information field; forming the decision context information payload corresponding to each constraint decision node hit by the change node, used to determine the risk level and risk basis of the change node. This payload assembly process is a direct manifestation of the graph database's topology traversal capability in the risk control process. The system not only extracts the attributes of the constraint decision node itself, but also extracts the code patterns, historical failure trajectories, and current compromise states connected along the relation edges, forming a complete decision context information payload. This payload serves as both the input basis for the downstream quantitative engine to calculate the risk level and the data source for the front-end decision card to render the risk basis.

[0192] Finally, to ensure the mandatory interaction attribute of the high-risk warning sub-interface, in response to the high-risk sub-interface being closed and no architectural compromise background information meeting the preset legality requirements being received through the high-risk sub-interface, the high-risk sub-interface is displayed again. This anti-closing mechanism is the defense line of the interactive state machine. If the reviewer attempts to ignore the decision card by clicking the close button or pressing the Esc key, the system will intercept the closing event and re-render the sub-interface. Only when the reviewer inputs architectural compromise background information meeting the legality requirements and submits it is the state machine allowed to transition to the unlocked state. This mandatory re-display mechanism ensures that the review process is not merely a formality, and that any architectural degradation must leave explicit decision traces. It should be understood that although this embodiment uses Zone Widget and state machine transitions as an example to illustrate the GUI implementation, in other embodiments, other front-end interception methods such as modal dialog box locking or disabling the approval button can also be used, as long as the functional requirements of mandatory interaction and data closure are met.

[0193] See Figure 6 The view control can be implemented as an inline view area of ​​the editor. Its key is not a specific API, but the risk control operation hierarchy based on risk level and constraint decision-making of the system, which actively changes the spatial layout of the code review interface: inserting interactive controls between the code line where the high-risk change node is located and the next line of code, so that the reviewer must make an explicit decision between the risk basis and the compromise input area, and cannot simply ignore the risk warning by scrolling the page.

[0194] like Figure 7 As shown, when a high-risk blockade occurs, the system's internal workflow logic may include: after detecting a high-risk node or event-level blockade, setting the approval control to an unavailable state; inserting a high-risk warning sub-interface between code lines; receiving architecture compromise background information; performing a preset legality check on the architecture compromise background information; if it does not meet the legality requirements, maintaining the blockade and re-displaying the high-risk sub-interface; if it meets the legality requirements, constructing a compromise decision node, writing it back to the graph database, establishing the association between the compromise decision and related constraint decision nodes, and then lifting the approval blockade. In addition, the system will record the expiration time of the compromise decision, triggering a code repair alarm after expiration. After the repair is completed, a code repair record node will be constructed, associating the repair record with the compromise decision node.

[0195] Example 6

[0196] To more clearly illustrate the executability and closed-loop governance effect of each module of this invention in a real business environment, the following example uses a scenario of an emergency access to a new type of digital token by a payment gateway, combined with... Figure 8The runtime full-link sequence execution timing diagram is used to trace all the abstract mechanisms of the first five embodiments. It should be understood that the specific code snippets, JSON payloads, and Cypher statements described in this embodiment are for interpretation only, not for limitation, and are intended to demonstrate the system's end-to-end closed-loop control capability from Git commit to GUI blocking and then to compromised database insertion, rather than limiting the invention to be applicable only to specific programming languages ​​or specific database query syntaxes.

[0197] In this scenario, a constraint decision node has been pre-built in the decision memory of the enterprise's core payment system. Its node identifier is UUID-DC-90182. The constraint intent field prohibits unbounded enumeration of the payment gateway, the risk weight field W_risk is 4.8, and the risk control operation level field is an event-level blocking level. The existence of this constraint decision represents the structured accumulation of lessons learned from past pitfalls by senior engineers, such as the historical experience of a payment routing state machine deadlock caused by hard-coding the newly added ALIPAY_V2 branch.

[0198] Step S601: The developer submits a code change event for a hard-coded else if branch. The developer received an urgent request to integrate a new digital token payment channel. Using an AI programming assistant, they generated a shortcut code in the old code and submitted a Pull Request containing this difference, with the code change record identified as PR-5042. The modified code snippet adds a hard-coded else if (gateway === 'NEW_CRYPTO') branch after the original if condition logic, directly calling the cryptoAPI.transfer method without implementing the PaymentGateway interface for polymorphic routing. While this AI-generated code is correct in its local business logic and can quickly satisfy a single instruction, from a long-term architectural evolution perspective, it severely undermines the system's scalability, representing a typical architectural violation where locally correct but overall deviating from the overall architecture.

[0199] Step S602: Module 1 extracts AST features to find anti-patterns. In response to the code change event, the system obtains the code text before and after the change, and performs syntax tree parsing to generate the syntax tree before and after the change, respectively. By performing structured alignment and tree edit distance algorithms, the system identifies a new ElseIfStatement node under the original IfStatement node, as the change node. Before determining the change node, the system performs semantic noise filtering on the set of syntax tree edit operations, discarding whitespace characters and formatting adjustments, which have no substantial semantic impact, to ensure that only structural variations at the control flow and business logic levels enter the subsequent pipeline.

[0200] Subsequently, the system uses this changed node as the processing object, traversing upwards along the parent node pointer to extract host context information. It determines that the class name is `PaymentProcessor`, the method signature is `public asyncprocessPayment`, and the syntax tree depth is 3. Simultaneously, it traverses downwards through the subtree to extract local context information, determining its cyclomatic complexity increment to be 1, and extracts the string literal `NEW_CRYPTO`. When extracting contextual syntax structure features, the system uses a pre-defined Tree-sitter Query anti-pattern preflighter, hitting a hard-coded temporary mapping marker because this changed node is represented as a syntax tree structure in an `if` statement using a string literal as the comparison object. Simultaneously, the system extracts contextual code semantic features containing code snippets, method signatures, literal values, and anti-pattern markers. Finally, the system packages the above features into a structured information payload, in which each change node item includes a node identifier field, a change operation type field Insert, a node type field ElseIfStatement, a code snippet field, a context information field, and a structure information field. The structure information field explicitly records that the cyclomatic complexity increment field value is 1, the static anti-pattern hit label field is anti_pattern.hardcoded_if_mapping, and the literal field is NEW_CRYPTO.

[0201] Step S603: The module performs binary vector recall and graph traversal to lock the constraint decision. The system directly matches the context syntax structure features corresponding to the change node with the syntax tree trigger field of the constraint decision node in the graph database, and indirectly matches it with the syntax tree query field of the code pattern node, merging the two to remove duplicates. Since the change node hits the anti-pattern of hard-coded temporary mapping, the system indirectly matches the constraint decision node UUID-DC-90182, which prohibits unbounded enumeration, along the directed trigger relationship edge.

[0202] Simultaneously, the system converts the contextual code semantic features of the changed node into a code semantic vector and performs a similarity search on the semantic vector records in the vector database. The vector database retrieves the semantic vector record corresponding to this constraint decision node with a cosine similarity of 0.89. The system maps back to the graph database through the vector record identifier field, and again locks onto the UUID-DC-90182 node. The system merges and deduplicates the constraint decision nodes matched by syntax structure features and code semantic features, determining that all constraint decision nodes matched by this changed node are only UUID-DC-90182. Furthermore, the system queries the graph database for the code pattern nodes, historical code change record nodes, and compromise decision nodes connected to this constraint decision node, forming a decision context information payload, which includes records of failed paths that previously caused deadlock bugs due to hard-coded enumeration.

[0203] In step S604, module three substitutes the actual numerical values ​​to calculate the decision deviation. The system obtains the deterministic hit input parameters, topological degradation input parameters, and semantic violation input parameters corresponding to the changed node. Since the changed node hits the constraint decision through contextual grammatical structure features, H_i is 1, and the system calculates the deterministic hit input parameter M_hard = 1 × 4.8 = 4.8. If the changed node only hits through semantic features, M_hard will be set to 0 to prevent semantic masquerading from circumventing hard rule interception. However, in this scenario, there is a deterministic structure hit, so this setting logic is not triggered.

[0204] For the topological degradation input parameter, the system extracts the cyclomatic complexity increment ΔC=1 and the syntax tree depth Depth=3 from the numerical representation of structural complexity, and calculates D_topo = max(0, 1) × log2(3+1) = 2.0. Although this value is not high, it already indicates that the code structure is beginning to show a trend of increasing complexity.

[0205] For the semantic violation input parameters, the system constructs a semantic violation analysis payload in a pre-formatted format. The semantic field for the change node is filled with code snippets and literal values ​​of hard-coded else if branches, while the semantic field for the constraint decision is filled with the constraint intent to prohibit unbounded enumeration and the syntax tree trigger expression. The system calls a large language model to fill in the structured analysis results in the violation judgment field, semantic violation probability field, and violation reason field defined by the payload. The large language model returns a semantic violation probability P_i of 0.95, determining that the change does indeed violate the architectural intent of polymorphic routing. After verifying that the filled payload satisfies the structured output constraints, the system extracts the semantic violation probability. Combining the risk weight of 4.8 for the constraint decision, the system calculates the semantic violation input parameter P_weighted = max(0.95 × 4.8) = 4.56.

[0206] Ultimately, the system assigns corresponding calculation coefficients to these three input parameters. The calculation coefficient α=2.0 for the deterministic hit input parameter is greater than the calculation coefficient γ=1.5 for the semantic violation input parameter, and the calculation coefficient for the semantic violation input parameter is greater than the calculation coefficient β=0.5 for the topology degradation input parameter. This stepped coefficient constraint ensures that hard rules validated by historical lessons have veto power, preventing false positives due to model misjudgments or the gradual impact of topology decay diluting high risks. The system calculates the decision deviation S = 2.0 × 4.8 + 0.5 × 2.0 + 1.5 × 4.56 = 17.44 and performs truncation, resulting in a final risk score S_drift = 10.0. Since the difference between this risk score and the preset risk threshold of 2.0 is significantly greater than the preset difference of 2.0, the system determines the risk level of this changed node to be high risk.

[0207] Step S605: A red blocking card is inserted into the module's four-view control to lock the approval operation. Based on the high-risk level of the change node and the event-level blocking level of the hit constraint decision node, the system performs risk control operations in the code review interface. After the code line corresponding to the change node and before the next code line, the system inserts a view control with a preset height of 180 pixels to increase the spacing between code lines and visually block the reviewer's downward scrolling inertia. This view control is rendered as a high-risk prompt sub-interface, where the risk basis display area not only shows the risk basis on the node side and the constraint side, but also displays the historical decision basis, namely the failure trajectory of PR-2023, which caused a serious deadlock due to similar hard-coded enumeration, as well as the scoring contribution basis and semantic violation analysis basis. At the same time, the front-end interactive control state machine enters the BLOCKED_REVIEW state, locks the Approve Merge button, and sets its disabled attribute to true.

[0208] In step S606, the reviewer inputs the background information and expiration time of the architecture compromise. After seeing the red blocking card and historical failure trajectory, the reviewer confirms that the AI-generated code does indeed break the polymorphic architecture. However, due to the fact that there is only one hour left before the release, the business side requires mandatory deployment. The reviewer enters the following explanation text in the architecture compromise background information input area: "I am aware of the architecture risks. There is a big promotion tomorrow morning, so I will hard-code it first, and then refactor it immediately in the next sprint after the promotion." This text exceeds the preset length threshold of 20 characters, and the reviewer has entered the expiration date, which is set to expire in 7 days. At the same time, the system automatically associates the code change event identifier PR-5042, the high-risk change node identifier, and the related constraint decision node identifier UUID-DC-90182, making the architecture compromise background information meet the preset legality requirements.

[0209] Step S607: Unlock the state machine transition and write the compromise decision back to the graph database. In response to receiving architectural compromise background information that meets the preset legality requirements, the interactive control state machine triggers a transition, recalculates the button formula Enable(Approve) = (10.0 >= 4.0 AND Len(reason text) > 20) -> True, removes the blockade on the approval operation, and unlocks the Approve Merge button.

[0210] The system writes back the compromise decision, which includes background information on the architectural compromise, to the decision memory, establishing a link between the compromise decision and the relevant constraint decision nodes. Specifically, the system constructs compromise decision nodes, where the code event change identifier field indicates PR-5042, the constraint decision node identifier field indicates UUID-DC-90182, and the constraint decision context fields include decision-maker information, explanation of the architectural compromise reason, relevant code snippets, and the expiration time of the compromise decision. The system initiates a Cypher statement operation to the graph database, creating a TEMPORARY_TRADE_OFF relationship edge between the Commit node and the DecisionConstraint node, persisting the reason text, reviewer identifier, and expiration timestamp after 7 days. The technical effect of this closed-loop write-back mechanism is that it transforms the originally implicit, human-memory-dependent debt into explicit, machine-traceable structured data assets through behavior. Seven days later, when the compromise decision expires, the system will automatically trigger a code repair alert, prompting the system to refactor and repair the hard-coded branch based on the compromise decision node and the constraint decision node. After the repair is completed, a code repair record node will be built and associated with the compromise decision node, thereby ensuring that technical debt does not accumulate indefinitely and achieving closed-loop and convergent decision governance.

[0211] It should be understood that although this embodiment uses TypeScript code snippets, JSON payloads, and Neo4j Cypher statements as examples to illustrate executability, in other embodiments, other programming languages ​​such as Java and Python, other search engines such as ElasticSearch, or other relational databases such as MySQL combined with vector search plugins can also be used to achieve the same data flow and logical judgment steps, as long as the closed-loop control function from structure tree extraction, vector and graph data retrieval, multivariate floating-point mathematical calculation, DOM node interception and rendering to graph database relationship writing is satisfied.

[0212] In addition, the present invention also provides a computer program product having at least one instruction stored thereon, wherein the at least one instruction, when executed by a processor, implements the method described above.

[0213] In addition, the present invention also provides a control system for code change approval, including one or more program modules, which are used to implement the method described above.

[0214] The above solution enables loosely coupled deployment and collaborative operation of the various components of the review pipeline by providing a modular system.

[0215] Furthermore, the present invention also provides a computer device, comprising: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed as described above.

[0216] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention, as long as they essentially implement the technical principles of one or more embodiments of the present disclosure, should be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A control method for code change approval, characterized in that, A decision memory is pre-constructed, comprising at least several constraint decisions for standardizing code architecture, each constraint decision being associated with feature matching conditions and risk identification strategies. The method includes: In response to a code change event, obtain the code text related to the code change event, and perform syntax tree parsing based on the code text to determine one or more syntax tree nodes involved in the code change as change nodes; For each change node, extract the contextual syntax structure features and / or contextual code semantic features corresponding to the change node; match the contextual syntax structure features and / or contextual code semantic features corresponding to the change node with the feature matching conditions associated with the constraint decisions in the decision memory to obtain the constraint decisions hit by the change node; determine the risk level of the change node based on the risk identification strategy associated with the constraint decisions hit by the change node. Risk control operations are performed in the code review interface based on the risk level of each change node; wherein, the risk control operations include at least: In response to the existence of at least one change node with a high risk level, the approval operation for the code change event is blocked; in response to receiving architectural compromise background information related to the constraint decision hit by the high-risk change node, and the architectural compromise background information meets the preset legality requirements, the blocking of the approval operation is lifted, the compromise decision containing the architectural compromise background information is written back to the decision memory, and the association between the compromise decision and the relevant constraint decision is established.

2. The method according to claim 1, characterized in that, The code text related to the code change event obtained includes: Obtain the code text of the file involved in the code change event before and after the change; Syntax tree parsing based on the code text includes: Perform syntax tree parsing on the code text before and after the change, respectively, to generate a syntax tree before and a syntax tree after the change; Identify one or more syntax tree nodes involved in the code changes as change nodes, including: Perform structured alignment on the syntax tree before and after the change to generate a set of syntax tree editing operations, and determine one or more syntax tree nodes based on the set of syntax tree editing operations; Perform structured alignment on the syntax tree before and after the change to generate a set of syntax tree editing operations, including: Determine the isomorphic mapping relationship between the syntax tree before the change and the syntax tree after the change; For syntax tree nodes that do not have an isomorphic mapping, generate at least one syntax tree editing operation among insertion, deletion, update, or move to obtain a set of syntax tree editing operations; Before determining the one or more change nodes based on the set of syntax tree edit operations, the method further includes: Semantic noise filtering is performed on the set of syntax tree edit operations, discarding syntax tree edit operations involving semantic noise; Among them, syntax tree editing operations involving semantic noise include at least one of whitespace characters, comments, formatting, and renaming; syntax tree editing operations not involving semantic noise include at least one of control flow, business logic, state judgment, exception handling, call relationship, and architecture boundary.

3. The method according to claim 1, characterized in that, Extract the contextual syntax structure features and / or contextual code semantic features corresponding to the change node, including: Taking the changed node as the processing object, obtain the node basic information, host context information and local context information corresponding to the changed node; wherein, the node basic information includes the change operation type and node type, the host context information is used to characterize the upper-level syntax structure of the changed node in the syntax tree, and the local context information is used to characterize the local syntax structure and local code content of the changed node itself and its subtrees. Based on the node's basic information, the host context information, and the local context information, generate the context syntax structure features and / or context code semantic features corresponding to the changed node.

4. The method according to claim 3, characterized in that, Also includes: Generate a structured information payload to characterize the code change event; wherein the structured information payload includes at least one or more change node items, and each change node item includes one or more fields for recording the context syntax structure features and / or context code semantic features corresponding to the change node.

5. The method according to claim 1, characterized in that, The decision memory includes a graph database, which stores several constraint decision nodes and several code pattern nodes in a directed graph topology structure. Each constraint decision node includes at least a constraint intent field and a syntax tree trigger field, wherein the syntax tree trigger field includes a syntax tree trigger expression; Each code pattern node includes at least a syntax tree query field, including the syntax tree query expression; Each code pattern node is connected to at least some constraint decision nodes via directed triggering edges, indicating that when the code pattern node is directly matched, the corresponding constraint decision node is indirectly matched along the directed triggering edges. The contextual grammatical structure features corresponding to the change node are matched with the feature matching conditions associated with the constraint decisions in the decision memory to obtain the constraint decisions matched by the change node, including: The context syntax structure features corresponding to the change node are matched with the syntax tree trigger field of the constraint decision node in the graph database to obtain the directly matched constraint decision node. The context syntax structure features corresponding to the change node are matched with the syntax tree query field of the code pattern node in the graph database to obtain the indirectly matched constraint decision node. The directly matched constraint decisions and the indirectly matched constraint decisions are merged and deduplicated to obtain the constraint decision nodes that the change node has matched.

6. The method according to claim 1 or 3, characterized in that, The decision memory includes a vector database, which includes several semantic vector records corresponding to constraint decisions. The context code semantic features corresponding to the change node are matched with the feature matching conditions associated with the constraint decisions in the decision memory to obtain the constraint decisions matched by the change node, including: The context code semantic features of the changed node are used to perform a similarity search on the semantic vector records in the vector database; The constraint decisions corresponding to the semantic vector records that meet the preset similarity conditions are used as the constraint decisions hit by the change node.

7. The method according to claim 3, characterized in that, The decision memory bank also includes a vector database, which includes semantic vector records; The constraint decision node in the graph database also includes a vector record identifier field; wherein, the vector record identifier field is used to map to the corresponding semantic vector record in the vector database, and the semantic vector record is obtained based on the semantics of at least one of the constraint intent field, syntax tree trigger field, and node type label of the corresponding constraint decision node; The context code semantic features corresponding to the change node are matched with the feature matching conditions associated with the constraint decisions in the decision memory to obtain the constraint decisions matched by the change node, including: The contextual code semantic features of the changed node are converted into code semantic vectors, and similarity searches are performed on the semantic vector records in the vector database. The constraint decision node corresponding to the semantic vector record that meets the preset similarity condition is taken as the constraint decision node hit by the change node. The method further includes: The constraint decision nodes that the change node is matched by through context code semantic features are merged and deduplicated with the constraint decision nodes that the change node is matched by through context syntax structure features, and these are taken as all the constraint decision nodes matched by the change node.

8. The method according to claim 3, characterized in that, The method further includes: Construct historical code change record nodes corresponding to the code change events, write the historical code change record nodes back to the graph database, and establish the association between the historical code change record nodes and the constraint decision nodes hit by each change node; The historical code change record node includes an event information field, or the constraint decision node connected to the historical code change record node includes the event information field; the event information field includes the node identifier of the historical code change record node, the historical code change timestamp, and the code fragment of the historical code change.

9. The method according to claim 3, characterized in that, At least some of the constraint decision nodes in the graph database also include a risk control operation level field, which is used to indicate the risk control operation that is forcibly executed in the code review interface; The risk control operations also include: In response to the risk control operation level being an event-level blocking level where at least one change node hits at least one constraint decision node, the approval operation for the code change event is blocked; in response to receiving architectural compromise background information related to the constraint decision node at the event-level blocking level, and the architectural compromise background information meeting preset legality requirements, the blocking of the approval operation is lifted, and the compromise decision containing the architectural compromise background information is written back to the decision memory, establishing the association between the compromise decision and the relevant constraint decision node.

10. The method according to claim 9, characterized in that, The compromise decision or the compromise decision node includes at least the following fields: The code event change identifier field is used to indicate the code change event involved in the compromise decision; The constraint decision node identifier field is used to indicate the constraint decision that is violated and circumvented by the compromise decision; The constraint decision context field is used to indicate the background of the architecture compromise decision; wherein, the constraint decision context field includes at least one of the following: decision-maker information field, explanation of the architecture compromise reason, relevant code snippet, and compromise decision expiration time; The method further includes: In response to the expiration time of any compromise decision node, a code repair alert is triggered to prompt the relevant code to be repaired based on the compromise decision node and its associated constraint decision nodes; In response to the completion of code repair, a corresponding code repair record node is constructed, and the association between the code repair record node and the compromise decision node is established; The risk control operations also include: In response to the presence of at least one change node with a risk level of high risk, or in response to the presence of at least one change node hitting at least one constraint decision node with a risk control operation level of event-level blocking level, query whether the relevant constraint decision node is associated with historical compromise decisions. If a historical compromise decision is found, it is determined whether the code change event matches the compromise background information of the historical compromise decision. If they match, the approval operation for the code change event is not blocked. If no historical compromise decision is found, or if it is determined that the code change event does not match the compromise background information of the historical compromise decision, the approval operation is blocked, and the system waits to receive the architectural compromise background information provided for the code change event.

11. The method according to claim 1, characterized in that, Based on the risk identification strategy associated with the constraint decision hit by the change node, determine the risk level of the change node, including: Obtain at least one of the following: deterministic hit input parameters, topology degradation input parameters, and semantic violation input parameters corresponding to the changed node; wherein, the deterministic hit input parameters are used to characterize the degree of violation of the canonical code architecture by the contextual syntactic structure features of the changed node, the topology degradation input parameters are used to characterize the degree of increase in code architecture complexity caused by the changed node, and the semantic violation input parameters are used to characterize the degree of violation of the canonical code architecture by the contextual code semantic features of the changed node; The decision deviation of the changed node is calculated based on at least one of the deterministic hit input parameters, the topology degradation input parameters, and the semantic violation input parameters, and the risk level of the changed node is determined based on the decision deviation.

12. The method according to claim 11, characterized in that, Obtain the deterministic hit input parameters corresponding to the change node, including: Based on the risk weights of one or more constraint decisions hit by the change node through contextual grammar structure features, the deterministic hit input parameters corresponding to the change node are calculated; wherein, the risk weight of each constraint decision hit by the change node through contextual grammar structure features is positively correlated with the deterministic hit input parameters corresponding to the change node.

13. The method according to claim 11, characterized in that, Obtain the topology degradation input parameters corresponding to the changed node, including: Extract the structural complexity numerical representation from the contextual syntax structure features of the changed node. The structural complexity numerical representation includes at least one of the following: cyclomatic complexity increment, syntax tree depth, maximum nesting depth, number of branches, number of conditional expressions, and number of loop structures. Based on the numerical representation of the structural complexity corresponding to the changed node, the topology degradation input parameters corresponding to the changed node are calculated; wherein, the numerical representation of the structural complexity corresponding to the changed node is positively correlated with the topology degradation input parameters corresponding to the changed node.

14. The method according to claim 11, characterized in that, Obtain the semantic violation input parameters corresponding to the changed node, including: For each constraint decision hit by the change node, based on the context code semantic features of the change node and the semantic features included in the constraint decision, the semantic violation information to be determined for the combination of the change node and the constraint decision is determined; the semantic features included in the constraint decision include at least one of the following: constraint intent, syntax tree trigger expression, and syntax tree query expression of the code pattern associated with the constraint decision. The large language model is invoked to analyze the semantic violation information of the combination formed by the change node and the constraint decision, and the semantic violation judgment result of the combination formed by the change node and the constraint decision is obtained; the semantic violation judgment result includes at least the semantic violation probability; Based on the semantic violation probability of the combination formed by the change node and each hit constraint decision, the semantic violation input parameters corresponding to the change node are obtained.

15. The method according to claim 14, characterized in that, The large language model is invoked to analyze the semantic violation information of the combination formed by the change node and the constraint decision, and the semantic violation analysis results of the combination formed by the change node and the constraint decision are obtained, including: Based on the semantic violation information to be determined by the combination of the change node and the constraint decision, a semantic violation analysis payload in a preset format is constructed; the semantic violation analysis payload includes a change node semantic field, a constraint decision semantic field, and a result filling field; the change node semantic field is used to fill in the context code semantic features of the change node; the constraint decision semantic field is used to fill in the semantic features included in the constraint decision; The semantic violation analysis payload is input into the large language model, and the large language model fills in the semantic violation analysis results in the result field defined by the semantic violation analysis payload; Extract the semantic violation analysis results from the entered semantic violation analysis payload.

16. The method according to claim 11, characterized in that, After calculating the decision deviation of the changed node, the following steps are also included: A scoring transformation process is performed on the decision deviation to obtain the risk score of the change node; wherein the scoring transformation process includes at least one of normalization processing, truncation processing, and interval mapping processing; The risk level of the change node is determined based on the decision deviation, including: The risk level of the changed node is determined based on the relationship between its risk score and a preset risk threshold. Specifically, if the risk score of the changed node is less than or equal to the preset risk threshold, the risk level is low risk; if the risk score of the changed node is greater than the preset risk threshold, the risk level is medium risk or high risk; if the difference between the risk score of the changed node and the preset risk threshold is greater than a preset difference, the risk level is high risk.

17. The method according to claim 1, characterized in that, The risk control operation also includes at least one of the following: When the risk level of the change node is low risk, perform a collapse operation on the code region corresponding to the change node. Alternatively, when the risk level of the change node is medium risk, a warning marker can be displayed in the code area or line number sidebar corresponding to the change node.

18. The method according to claim 1, characterized in that, The risk control operations also include: In response to the existence of at least one change node having a high risk level, or in response to the risk control operation level of at least one constraint decision triggered by at least one change node being an event-level blocking level, a high-risk warning sub-interface is displayed near the code area corresponding to the change node; wherein, the high-risk warning sub-interface includes a risk basis display area and an architecture compromise background information input area; A high-risk warning sub-interface is displayed near the code area corresponding to the change node, including: After the line of code corresponding to the change node and before the next line of code, a view control of a preset height is inserted. The view control is used to visually alert the approval operation. The view control includes a risk basis display area and an architecture compromise background information input area.

19. A computer program product, characterized in that, It stores at least one instruction, which, when executed by a processor, implements the method of any one of claims 1-18.

Images