A method, system, medium and product for checking and automatically repairing a full stack system

Abstract

A method, system, medium, and product for verification and automatic repair of a full-stack system, relating to the field of artificial intelligence, are disclosed. The method includes: acquiring an initial full-stack system configuration, a set of actual system entities, and front-end verification reference data; marking resource identifiers as phantom references when they do not match any of the actual entities; performing multi-level degradation matching to match real entities in the set of actual system entities and using them as repair identifiers; merging permission items when multiple phantom references match the same real entity; replacing the phantom references with the repair identifiers and updating the permission items to the merged permission items to obtain the repaired backend permission configuration; validating the front-end components and cross-layer binding information separately; and outputting the verification and repair results based on the front-end component verification results, the front-end cross-layer binding verification results, and the repaired backend permission configuration. This application can improve the automation and reliability of full-stack system configuration generation.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence, and in particular to a method, system, medium, and product for the verification and automatic repair of a full-stack system. Background Technology

[0002] With the widespread application of large language models in software engineering, AI agents can now directly generate structured full-stack system configurations, including permission policies, front-end component layouts, and API endpoint bindings. These configurations collectively define the complete behavior of the system, and there are numerous reference relationships between different layers of configuration. For example, permission configurations need to reference specific workflow names, and front-end components need to be bound to back-end API endpoint addresses. However, large language models suffer from the illusion problem, which may fabricate non-existent entity names or fictitious API endpoint addresses. This results in a large number of unresolved references in the generated configurations, leading to runtime errors such as permission verification failures and 404 API call errors after system deployment, severely impacting system availability.

[0003] To address the issue of invalid references in AI-generated configurations, existing technologies propose a constraint-driven self-healing method. By predefining a domain constraint system, the method guides the model to output intermediate representations that conform to the specifications during the generation process. Subsequently, correction prompts are constructed for entries that fail verification, and the model is called again for repair until the quality threshold is met.

[0004] However, when applied to full-stack system configuration scenarios, due to the existence of cross-layer references in the configuration, the repair process requires multiple calls to the model to process the configuration items that failed to be verified. When it is detected that the backend API endpoint address bound to the frontend component cannot be resolved, a prompt word needs to be constructed and the model needs to be called again to generate the correct address. However, the model may fabricate a non-existent endpoint or change other originally correct references in the configuration during the second generation. This results in multiple model calls required to repair a single configuration, extending the repair cycle and reducing the predictability of the repair results, thereby affecting the automation and reliability of full-stack system configuration generation. Summary of the Invention

[0005] This application provides a method, apparatus, device, and medium for verifying and automatically repairing a full-stack system, which addresses the technical problem of how to improve the automation and reliability of full-stack system configuration generation.

[0006] In a first aspect, embodiments of this application provide a method for verification and automatic repair of a full-stack system, including: Obtain the initial full-stack system configuration, the actual system entity set, and the front-end verification reference data. The initial full-stack system configuration includes backend permission configuration and front-end design configuration. The backend permission configuration contains at least one resource identifier, and the front-end design configuration contains front-end components and cross-layer binding information for binding backend API endpoints. The initial full-stack system configuration is pre-generated by the large language model. Compare each resource identifier with the actual entities in the system's actual entity set; When a resource identifier is inconsistent with all actual entities, the resource identifier is marked as a ghost reference; Based on the actual entity set of the system, the ghost references are matched in a multi-level downgraded manner according to the preset matching order until a real entity is successfully matched in the actual entity set of the system, and the real entity is used as the repair identifier for the ghost reference. When multiple ghost references match the same real entity, the permission items corresponding to the multiple ghost references are merged to obtain the merged permission items; Replace the ghost reference with the corresponding repair identifier to obtain the repaired ghost reference, and update the permission item corresponding to the repaired ghost reference with the corresponding merged permission item to obtain the repaired backend permission configuration. Based on the repaired backend permission configuration and frontend verification reference data, the validity of frontend components and cross-layer binding information is verified to obtain the frontend component verification result and the frontend cross-layer binding verification result. Based on the front-end component validation results, the front-end cross-layer binding validation results, and the repaired back-end permission configuration, the validation and repair results of the initial full-stack system configuration are output.

[0007] Optionally, based on the system's actual entity set, the phantom reference is subjected to multi-level downgrade matching according to a preset matching order until a real entity is successfully matched in the system's actual entity set. The real entity is then used as the repair identifier for the phantom reference. This includes: based on the first-level matching strategy, determining whether there exists a first real entity in the system's actual entity set whose entity name corresponds to the value of the phantom reference; if a first real entity exists, it is used as the repair identifier for the phantom reference; if no first real entity exists, based on the second-level matching strategy, determining whether there exists a second real entity in the system's actual entity set whose entity identifier ID corresponds to the value of the phantom reference. If a second real entity exists, it is used as the repair identifier. If no second real entity exists, the third-level matching strategy is used to determine whether the number of instances of the entity type corresponding to the ghost reference in the actual entity set of the system is unique. If the number of instances is unique, the ghost reference is mapped to the unique instance as the third real entity, and the third real entity is used as the repair identifier. If the number of instances is not unique, the fourth-level matching strategy is used to determine whether there is a fourth real entity in the sub-operator names contained in the entity of the actual entity set that corresponds to the value of the ghost reference. If a fourth real entity exists, it is used as the repair identifier.

[0008] Optionally, when multiple ghost references match the same real entity, the permission items corresponding to the multiple ghost references are merged to obtain merged permission items. This includes: obtaining multiple permission items corresponding to the target ghost reference in the backend permission configuration, each permission item containing at least one permission operation, and the target ghost reference being any ghost reference among the multiple ghost references matching the same real entity; establishing an aggregation mapping table with the identifier of the same real entity as the unique key value; for the same permission operation, if the permission status of the permission operation of any ghost reference among the multiple ghost references is allowed, then setting the permission status after aggregation to allowed and writing it into the aggregation mapping table to overwrite the original permission status, obtaining an aggregation mapping table after union processing; and generating merged permission items based on the aggregation mapping table after union processing.

[0009] Optionally, based on the front-end verification reference data, validity checks are performed on the front-end components and cross-layer binding information respectively to obtain the front-end component verification result and the front-end cross-layer binding verification result, including: if the front-end component exists in the component registration data, the component existence verification result is marked as existing; if the front-end component does not exist in the component registration data, the preset component source is queried; if the front-end component exists in the preset component source, the component existence verification result is marked as pending installation; if the front-end component does not exist in the preset component source, the component existence verification result is marked as non-existent; when the component existence verification result is existing or pending installation, the preset component metadata corresponding to the front-end component that passed the component existence verification is obtained, and the value type of each attribute in the attribute configuration of the front-end component is compared with the expected attribute type in the preset component metadata to obtain... The process involves several steps: obtaining the attribute type compatibility check result; generating a front-end component check result based on the component existence check result and the attribute type compatibility check result; extracting the back-end API endpoint bound in the attribute configuration; querying the existence of the back-end API endpoint based on the deployed endpoint data; if it exists, sending an HTTP request to the back-end API endpoint to verify endpoint reachability, and obtaining the endpoint reachability check result; obtaining the output data format description of the back-end API endpoint and the expected input data structure of the front-end component; when a required field in the expected input data structure is missing in the output data format description, marking the cross-layer binding relationship between the front-end component and the back-end API endpoint as data structure incompatibility, and obtaining the data format compatibility check result; and using the endpoint reachability check result and the data format compatibility check result as the cross-layer binding check result.

[0010] Optionally, the method also includes: obtaining the client's request text, determining the operation mode corresponding to the request text through a preset intent keyword model; if the operation mode is read-only verification mode, disabling the modification execution tool, generating and outputting a text verification report with a three-level classification structure based on the front-end component verification results, the front-end cross-layer binding verification results, and the back-end permission configuration that has not yet replaced the repair identifier; if the operation mode is write repair mode, replacing the ghost reference in the back-end permission configuration with the repair identifier through the modification execution tool, and outputting the repaired back-end permission configuration.

[0011] Optionally, before obtaining the initial full-stack system configuration, the actual set of system entities, and the front-end verification reference data, the method further includes: monitoring the actual set of system entities and identifying the actual backend workflow entities and operator entities in the current system; extracting standardized entity names from the backend workflow entities and operator entities to construct a structured authoritative name vocabulary; converting the authoritative name vocabulary into name constraint information with exclusive constraint rules according to a preset prompt word guidance template; concatenating the name constraint information to the end of the system prompt words of the large language model and using a context window to perform knowledge anchoring on the large language model to obtain a knowledge-anchored large language model; executing a configuration generation task through the knowledge-anchored large language model, whereby the knowledge-anchored large language model, when outputting the initial full-stack system configuration, restricts the generation space of resource identifiers in the initial full-stack system configuration to the range of name constraint information, thereby reducing the probability of illusions in the initial full-stack system configuration.

[0012] Optionally, after outputting the verification and repair results of the initial full-stack system configuration, the method further includes: establishing a backend layer event listener for the deployed full-stack system, and capturing dynamic configuration change events of backend API endpoints through the backend layer event listener; when a dynamic configuration change event is captured, parsing the source endpoint routing address affected by the configuration change event; traversing cross-layer binding information, extracting the attribute configuration of the frontend components from the cross-layer binding information, and filtering out the associated frontend components bound to the source endpoint routing address in the attribute configuration; if the dynamic configuration change event is an endpoint routing address change, marking the cross-layer binding status of the associated frontend components as stale binding, and generating an automatic repair suggestion to update the stale binding to the changed routing address; if the dynamic configuration change event is the deletion of a backend workflow entity or operator entity, marking the cross-layer binding status of the associated frontend components as broken binding, blocking automatic repair, and generating a cross-layer topology blocking work order with error breakpoints.

[0013] Secondly, embodiments of this application provide a verification and automatic repair system for a full-stack system. The verification and automatic repair system for a full-stack system includes: one or more processors and a memory; the memory is coupled to one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and one or more processors call the computer instructions to cause the verification and automatic repair system for the full-stack system to perform the method described in the first aspect and any possible implementation thereof.

[0014] Thirdly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a full-stack system verification and automatic repair system, cause the full-stack system verification and automatic repair system to execute the method described in the first aspect and any possible implementation thereof.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a full-stack system verification and automatic repair system, cause the full-stack system verification and automatic repair system to perform the method described in the first aspect and any possible implementation thereof.

[0016] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages: 1. By comparing resource identifiers in the backend permission configuration with the actual set of system entities to mark phantom references, performing multi-level degradation matching on phantom references to obtain repair identifiers, merging permission items when multiple phantom references match the same real entity, replacing the phantom references and updating the permission items to obtain the repaired backend permission configuration, and then validating the frontend components and cross-layer binding information, the system achieves automated detection and repair of reference integrity issues in AI-generated full-stack system configurations. This avoids runtime failures caused by configuration errors due to AI illusions after deployment, significantly improving the reliability and automation level of full-stack system configuration.

[0017] 2. By employing a multi-level degradation matching strategy, ghost references are gradually mapped to the most likely real entities. When multiple ghost references match the same real entity, they are merged through permission operation logic or calculation. Simultaneously, multi-level validity verification of front-end components and cross-layer bindings is performed through component existence verification, attribute type compatibility verification, endpoint reachability verification, and data format compatibility verification. This forms a unified verification and repair framework covering the back-end permission layer, front-end component layer, and cross-layer API binding layer. Even when exact matching fails, ghost references can still be automatically repaired through degradation strategies, and runtime errors are transformed into pre-deployment predictable verification results, significantly enhancing the consistency and stability of the full-stack system configuration.

[0018] 3. By determining the operation mode based on intent keywords, the modification execution tool is disabled in read-only verification mode, and the repair operation is performed in write repair mode. This achieves strict separation between verification and repair operations, avoiding the risk of accidental configuration modification during verification. By building an authoritative glossary of names and embedding prompt words from the large language model system before configuration generation, the probability of phantom references is reduced from the generation stage, forming a complete closed loop of "prevention + detection + repair" with the subsequent detection and repair mechanism. By establishing a backend layer event listener to capture configuration change events, filtering related frontend components bound to the affected address and marking the cross-layer binding status, proactive perception of configuration changes in deployed systems and automatic detection of cross-layer reference failures are achieved, improving the maintainability and reliability of the full-stack system during continuous evolution. Attached Figure Description

[0019] Figure 1This is a flowchart illustrating the verification and automatic repair method for a full-stack system provided in this application embodiment; Figure 2 This is another flowchart illustrating the verification and automatic repair method for a full-stack system provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of a full-stack system verification and automatic repair system provided in an embodiment of this application.

[0020] Explanation of reference numerals in the attached drawings: 501, Central Processing Unit; 502, Read-Only Memory; 503, Random Access Memory; 504, Bus; 505, Input / Output Interface; 506, Input Section; 507, Output Section; 508, Storage Section; 509, Communication Section; 510, Driver; 511, Removable Media. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] In the description of the embodiments of this application, words such as "illustrative," "for example," or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "illustrative," "for example," or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Rather, the use of words such as "illustrative," "for example," or "for example" is intended to present the relevant concepts in a specific manner.

[0023] In the description of the embodiments of this application, the terms "first, second, third" are used only to distinguish similar objects and do not represent a specific order of objects. It is understood that "first, second, third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0024] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0025] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant national laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0026] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0027] This application provides a method, system, medium, and product for the verification and automatic repair of a full-stack system, which addresses the technical problem of how to improve the automation and reliability of full-stack system configuration generation.

[0028] Figure 1 This is a flowchart illustrating the verification and automatic repair method for a full-stack system provided in this application embodiment.

[0029] This application discloses a method for verification and automatic repair of a full-stack system, such as... Figure 1 As shown, the steps include the following.

[0030] S101. Obtain the initial full-stack system configuration, the actual system entity set, and the front-end verification reference data. The initial full-stack system configuration includes backend permission configuration and front-end design configuration. The backend permission configuration contains at least one resource identifier. The front-end design configuration contains front-end components and cross-layer binding information for binding backend API endpoints. The initial full-stack system configuration is pre-generated by the large language model.

[0031] Specifically, the system obtains the initial full-stack system configuration pre-generated by the large language model. This initial full-stack system configuration includes two parts: backend permission configuration and frontend design configuration. The backend permission configuration contains at least one resource identifier, which points to the actual entity object in the system. The frontend design configuration contains frontend components and cross-layer binding information for binding backend API endpoints. The cross-layer binding information records the association between frontend component attributes and backend API endpoints. Simultaneously, the system obtains the actual entity set, which includes the set of workflow entities, operator entities, and entity names currently deployed in the system. This set serves as the basis for subsequent verification of the existence of resource identifiers. Furthermore, the system obtains frontend verification reference data, which includes component registration data and deployed endpoint data. The component registration data records the information of frontend components registered in the system, and the deployed endpoint data records the information of backend API endpoints deployed in the system.

[0032] The initial full-stack system configuration refers to structured configuration data automatically generated by the large language model based on user requirements, used to define the permission policies and front-end interface layout of the full-stack system. Backend permission configuration refers to configuration data used to define user or role access permissions to system resources. Resource identifiers are names or IDs used to uniquely identify system entities, pointing to specific workflows, operators, or entity objects in the backend permission configuration. Frontend design configuration refers to configuration data used to define the frontend page structure and component layout. Frontend components are reusable UI units that constitute the frontend user interface. Cross-layer binding information refers to configuration data in frontend component properties used to bind backend API endpoints, establishing data associations between frontend components and backend services. Backend API endpoints are the interface addresses exposed by backend services, used to receive frontend requests and return data. The system actual entity set refers to the collection of entity objects actually deployed and in an available state in the current system. Frontend verification reference data refers to the reference data set used to verify the validity of frontend components and cross-layer bindings, including component registration data and deployed endpoint data.

[0033] Figure 2 This is another flowchart illustrating the verification and automatic repair method for a full-stack system provided in this application embodiment.

[0034] Based on the above embodiments, as an optional embodiment, see [link to embodiment]. Figure 2 ,exist Figure 1 Before step S101 shown, steps S201-S205 may also be included, which will be explained in detail below.

[0035] S201, The actual entity set of the monitoring system, identifies the actual backend workflow entities and operator entities in the current system.

[0036] Specifically, the system monitors the actual entity set and identifies the backend workflow entities and operator entities currently deployed in the system. Backend workflow entities refer to the workflow instances currently available in the system, each containing a workflow identifier and a workflow name. Operator entities refer to the operator instances currently available in the system, each containing an operator identifier and an operator name. By continuously monitoring changes in the actual entity set, the system obtains the latest complete list of backend workflow entities and operator entities, which serves as the raw data source for subsequently building an authoritative glossary.

[0037] S202. Extract standardized entity names from backend workflow entities and operator entities, and construct a structured authoritative glossary of names.

[0038] Specifically, canonical entity names are extracted from the identified backend workflow entities and operator entities. Canonical entity names refer to the standardized names recorded in the system registry, which follow the system's preset naming conventions and do not contain aliases, abbreviations, or non-standard variations. The extracted canonical entity names are then categorized and organized according to entity type to construct a structured authoritative name glossary. This authoritative name glossary is stored in key-value pair format, where the key represents the entity type and the value represents a list of canonical names for all entities under that type. This glossary is used to constrain the generation space of the large language model in the future.

[0039] Among them, the canonical entity name refers to the standardized name of an entity that is officially registered in the system and used for reference, ensuring consistency in referencing the same entity across different modules. The authoritative name vocabulary is a collection containing the canonical names of all actual entities in the system, serving as the sole reliable source for constraining the range of large language model generation. This vocabulary is stored in a structured data format and includes entity type identifiers and a list of names for the corresponding types.

[0040] For example, the specification name "Image Preprocessing" is extracted from the identified workflow entity "wf_001", the specification name "Target Recognition" is extracted from the workflow entity "wf_002", the specification name "Image Cropping" is extracted from the operator entity "op_001", the specification name "Radiometric Correction" is extracted from the operator entity "op_002", and the specification name "Target Detection" is extracted from the operator entity "op_003". These specification names are organized by type to construct an authoritative glossary: ​​the list of names corresponding to the workflow type is ["Image Preprocessing", "Target Recognition"], and the list of names corresponding to the operator type is ["Image Cropping", "Radiometric Correction", "Target Detection"]. This glossary is stored as structured data in JSON format.

[0041] S203. Following the preset prompt word guidance template, convert the authoritative glossary of names into name constraint information with exclusive constraint rules.

[0042] Specifically, following the preset prompt-guided template, the constructed authoritative name vocabulary is converted into name constraint information with exclusive constraint rules. The preset prompt-guided template defines the format rules for converting structured data into natural language constraints. This template includes entity type identifier placeholders, name list placeholders, and exclusive constraint statement templates. By filling the corresponding placeholder positions in the template with entity types and corresponding canonical name lists from the authoritative name vocabulary, complete name constraint information is generated. This name constraint information explicitly includes an exclusive constraint rule of "must be selected from the following list," which is used to limit the range of entity names that the large language model can use when generating the configuration.

[0043] The prompt word guidance template refers to a predefined format specification for converting structured data into binding prompt text. This template defines the organization and expression of entity types, name lists, and constraint rules within the prompt text. Name constraint information refers to the binding text used to embed prompt words in the large language model system. This information includes identifiers for entity types, a complete list of all legal names under the corresponding type, and exclusive rules explicitly prohibiting the use of names outside the list. Exclusive constraint rules are mandatory instructions requiring the large language model to use only the names explicitly listed in the constraint information when generating configurations, prohibiting the fabrication or reference of any names outside the list.

[0044] S204. Concatenate the name constraint information to the end of the system prompt word of the large language model, and use the context window to anchor the knowledge of the large language model to obtain the knowledge-anchored large language model.

[0045] Specifically, the generated name constraint information is appended to the end of the system prompt word of the large language model. The system prompt word is the initial instruction text used to guide the behavior pattern of the large language model. The name constraint information is appended to the system prompt word in natural language form to form a complete prompt input. The prompt input is processed using the context window of the large language model. The context window refers to the maximum text length range that the large language model can receive and process in one inference. By placing the complete prompt input containing name constraint information within the context window, the large language model can use the constraint information as a reference knowledge basis when generating configurations, thus achieving knowledge anchoring and obtaining a knowledge-anchored large language model. This model uses the name constraint information as a generation boundary that must be followed in the subsequent configuration generation process.

[0046] System prompts refer to predefined guiding text for the behavior of the large language model, used to set the model's task objectives, output format, and generation specifications. The context window refers to the maximum text length limit that the large language model can handle in a single inference iteration, usually measured in tokens, and is used to carry the entire content of the input prompts and generated output. The knowledge-anchored large language model refers to a large language model instance in a state of pending generation after being constrained by the input prompts; its generation behavior is guided and limited by the provided constraint information.

[0047] For example, the system prompt is: "You are a full-stack system configuration generation assistant. Please generate backend permission configuration in YAML format and frontend design configuration in JSON format according to user needs." The workflow name constraint information "##Workflows in the current project (2 in total)\n-Image Preprocessing\n-Target Recognition\nWorkflow names in the YAML configuration must be precisely selected from the above list; fabrication is prohibited." and the operator name constraint information are concatenated to the end of this prompt to form a complete prompt input. This complete prompt input is then sent to the context window of the large language model. After receiving this prompt input, the large language model uses the name constraint information as a rule that must be followed when generating the configuration, forming a knowledge-anchored large language model.

[0048] S205. The configuration generation task is performed through the knowledge-anchored large language model. When the knowledge-anchored large language model outputs the initial full-stack system configuration, the generation space of resource identifiers in the initial full-stack system configuration is restricted to the range of name constraint information, so as to reduce the probability of illusion in the initial full-stack system configuration.

[0049] Specifically, the knowledge-anchored large language model performs a configuration generation task. This task refers to the process of generating initial full-stack system configuration instructions based on user requirements. After receiving user requirements, the large language model performs reasoning and generation based on system prompts and name constraint information. When the knowledge-anchored large language model outputs the initial full-stack system configuration, it restricts the generation space of resource identifiers in the initial full-stack system configuration to the range of name constraint information. The generation space refers to the set of tokens that the large language model can choose when generating text. Through the exclusive constraint rules in the name constraint information, when the large language model generates resource identifier-related fields, its token selection is limited to the range of tokens corresponding to the legal names explicitly listed in the name constraint information. It is prohibited to select any tokens outside this range. As a result, when the model outputs the initial full-stack system configuration, all resource identifiers come from the canonical entity names listed in the name constraint information, thereby reducing the probability of illusions caused by model fabrication in the initial full-stack system configuration.

[0050] In this context, the generation space refers to the set of tokens available to the large language model at each step when generating text token by token. This set is determined by the model's vocabulary and the current context. The illusion probability refers to the likelihood that the large language model will fabricate non-existent entity names when generating content.

[0051] S102. Compare each resource identifier with the actual entities in the system's actual entity set.

[0052] Specifically, each resource identifier in the backend permission configuration is compared one by one with the actual entities in the system's actual entity set. Using the value of the resource identifier as the query condition, each actual entity in the system's actual entity set is traversed to determine whether the value of the resource identifier is completely consistent with the identifier or specification name of any actual entity. If a consistent actual entity is found, the resource identifier is determined to be a valid reference. If no consistent actual entity is found after the traversal, the resource identifier is determined to be unable to match the current state of the system.

[0053] In this context, an actual entity refers to a specific entity object that is actually deployed in the system and is in an available state. Each actual entity contains two attributes that can be used for matching: an entity identifier and an entity specification name.

[0054] S103. When a resource identifier is inconsistent with all actual entities, mark the resource identifier as a ghost reference.

[0055] Specifically, after comparing each resource identifier in the backend permission configuration with the actual entities in the system's actual entity set one by one, if the value of the resource identifier is not equal to the identifier and canonical name of all actual entities in the system's actual entity set, the resource identifier is determined to be an invalid reference and marked as a ghost reference. This status mark is used to record that the resource identifier cannot find a corresponding entity in the current system's actual entity set. It belongs to the phantom reference generated during AI-generated configuration and needs to be processed in subsequent processes through multi-level downgrade matching and repair. The marked ghost reference is distinguished from the valid references existing in the configuration to ensure that the subsequent repair process can accurately identify the invalid reference entries that need to be processed.

[0056] Among them, ghost references refer to resource identifiers that point to entities that do not exist in the system. The references cannot be found in the actual set of entities in the system, and are phantom references generated when the configuration is generated by AI.

[0057] Through the above embodiments, accurate identification and status recording of phantom references in AI-generated configurations are achieved. This marking mechanism transforms the verification results into traceable and processable status data, providing a clear processing target for subsequent multi-level downgrade matching and permission item merging. At the same time, by distinguishing between valid and invalid references through status identifiers, the subsequent repair process can focus on handling phantom references without repeatedly performing existence checks, thus improving overall processing efficiency.

[0058] S104. Based on the actual set of entities in the system, perform multi-level downgrade matching on the ghost references in a preset matching order until a real entity is successfully matched in the actual set of entities in the system, and use the real entity as the repair identifier for the ghost references.

[0059] Specifically, based on the system's actual entity set, resource identifiers marked as phantom references are subjected to multi-level degradation matching in a preset matching order. The preset matching order refers to the order in which the matching strategies at each level are executed, arranged from high to low matching strictness. Multi-level degradation matching refers to a matching mechanism that includes at least two levels of matching strategies, where the matching strictness of the later matching strategy is lower than that of the earlier matching strategy. Each matching strategy attempts to establish a correspondence between the value of the phantom reference and the actual entity in the system's actual entity set. When a matching strategy at a certain level successfully matches an actual entity, the execution of subsequent matching strategies at each level is stopped. The successfully matched actual entity is taken as the real entity, and the identifier corresponding to the real entity is taken as the repair identifier for the phantom reference. The repair identifier is used to replace the original phantom reference in subsequent steps.

[0060] The preset matching order refers to the predefined execution order of each level of matching strategy, set from highest to lowest matching precision. Multi-level degradation matching refers to a mechanism that uses multiple matching strategies to sequentially attempt to establish an association between the ghost reference and the actual entity. Each level of matching strategy uses different matching rules, with later levels having more lenient matching conditions than earlier levels. The real entity refers to the actual entity object that successfully establishes a correspondence with the ghost reference through the matching strategy; this entity exists in the system's set of actual entities. The repair identifier is the identifier of the real entity, used to replace the original ghost reference, ensuring that the repaired configuration correctly points to the actual entity existing in the system.

[0061] Through the above embodiments, when exact matching fails, a more lenient matching strategy can be automatically tried to maximize the mapping of AI-generated phantom references to actual entities in the system. Compared with only exact matching, this multi-level degradation matching mechanism significantly improves the success rate of automatic repair of phantom references. At the same time, by pre-setting the matching order, the matching strategy with the highest accuracy is ensured to be used first, and the repairable range is expanded as much as possible while ensuring the accuracy of repair, effectively reducing the need for manual intervention in handling phantom references.

[0062] Based on the above embodiments, as an optional embodiment, for Figure 1 The step S104 shown can be implemented through steps S1041-S1048, which will be explained in detail below.

[0063] S1041. Based on the first-level matching strategy, determine whether there exists a first real entity in the actual entity set of the system whose entity name corresponds to the value of the ghost reference.

[0064] Specifically, based on the first-level matching strategy, the value of the ghost reference is used as a query condition. The system iterates through the canonical name field of each actual entity in the actual entity set to determine whether there is any actual entity whose canonical name is exactly the same as the value of the ghost reference. The canonical name refers to the standardized name recorded by the entity in the system registry. This name follows the system's preset naming conventions and does not contain aliases, abbreviations, or non-standard variations. "Completely the same" means that the string value of the ghost reference is completely identical to the string of the canonical name of the actual entity at the character level, including uppercase and lowercase letters, spaces, and special characters. When there is an actual entity whose canonical name is exactly the same as the value of the ghost reference, this actual entity is taken as the first real entity. The first real entity refers to the actual entity object that is successfully matched through the first-level matching strategy and is used as a candidate target for subsequent repair operations.

[0065] The first-level matching strategy is the most stringent matching method among the multi-level downgraded matching. This strategy requires that the value of the ghost reference exactly match the canonical name of the actual entity. The canonical name refers to the standardized name recorded in the system registry of the entity, used as the standard form for entity reference. The first real entity is the actual entity object successfully matched through the first-level matching strategy, whose canonical name is completely identical to the value of the ghost reference.

[0066] For example, the system's actual entity set includes workflow entity "wf_001" with the specification name "Image Preprocessing", workflow entity "wf_002" with the specification name "Target Recognition", operator entity "op_001" with the specification name "Image Cropping", operator entity "op_002" with the specification name "Radiometric Correction", and operator entity "op_003" with the specification name "Target Detection". If the ghost reference value is "Image Preprocessing", and the specification names of all entities in the system's actual entity set are traversed, the specification name "Image Preprocessing" of workflow entity "wf_001" is found to be exactly the same as the ghost reference value "Image Preprocessing", then workflow entity "wf_001" is selected as the first real entity. If the ghost reference value is "Image Preprocessing Flow", and all specification names are different from "Image Preprocessing", "Target Recognition", "Image Cropping", "Radiometric Correction", and "Target Detection", then the first-level matching strategy did not match the first real entity.

[0067] S1042. If a first real entity exists, then the first real entity shall be used as the repair identifier for the ghost reference.

[0068] Specifically, when the first-level matching strategy successfully matches the first real entity, the value of the entity identifier field is extracted from the data structure of the first real entity, and the value is assigned to the repair identifier variable corresponding to the ghost reference. This completes the mapping and binding between the ghost reference and the real entity, so that the ghost reference obtains a valid identifier pointing to the actual entity in the system, which is used to update the original ghost reference to the correct entity reference in the subsequent replacement steps.

[0069] S1043. If there is no first real entity, then based on the second-level matching strategy, determine whether there is a second real entity in the actual entity set of the system that corresponds to the value of the entity identifier ID and the ghost reference.

[0070] Specifically, when the first-level matching strategy fails to match the first real entity, the second-level matching strategy is executed. The value of the ghost reference is used as the query condition. The entity identifier field of each real entity in the system's real entity set is traversed. The entity identifier of each real entity is compared with the value of the ghost reference. If the entity identifier of a real entity is exactly the same as the value of the ghost reference, then the real entity is determined as the second real entity, and the matching process of the second-level matching strategy is completed.

[0071] The second-level matching strategy refers to the second most stringent matching method in the multi-level downgrading matching. This strategy requires the value of the phantom reference to match exactly with the entity identifier of the actual entity. The entity identifier ID is a unique identification code assigned by the system to each actual entity, used to identify and locate the entity within the system, and is usually stored as a string. The second real entity refers to the actual entity object successfully matched through the second-level matching strategy, whose entity identifier is completely identical to the value of the phantom reference.

[0072] S1044. If a second real entity exists, then the second real entity shall be used as the repair identifier.

[0073] Specifically, when the second-level matching strategy successfully matches the second real entity, the value of the entity identifier field is extracted from the data structure of the second real entity, and the value is assigned to the repair identifier variable corresponding to the ghost reference. This establishes a mapping relationship between the ghost reference and the second real entity, so that the ghost reference obtains a valid identifier pointing to the actual entity in the system. This identifier is then used in subsequent replacement steps to update the original ghost reference to the correct entity reference.

[0074] S1045. If there is no second real entity, then based on the third-level matching strategy, determine whether the number of instances of the entity type corresponding to the ghost reference in the actual entity set of the system is unique.

[0075] Specifically, when the second-level matching strategy fails to match a real entity, the third-level matching strategy is executed. The corresponding entity type is obtained from the context information of the configuration field where the ghost reference is located. All instances belonging to the entity type are filtered out from the actual entity set in the system. The number of filtered instances is counted, and it is determined whether the number of instances is equal to one. If the number of instances is one, it is determined that the unique condition is met; otherwise, it is determined that the unique condition is not met.

[0076] The third-level matching strategy refers to the matching method in multi-level degradation matching that automatically maps based on the number of entity type instances. Entity type refers to the resource category pointed to by the ghost reference in the configuration, determined by the context information of the configuration field where the ghost reference is located, including workflow type, operator type, or entity name type. Instance refers to a specific entity object belonging to a particular entity type in the actual entity set of the system; each instance contains an entity identifier and an entity canonical name.

[0077] S1046. If the number of instances is unique, then map the ghost reference to the unique instance as the third real entity, and use the third real entity as the repair identifier.

[0078] Specifically, when the third-level matching strategy determines that the number of instances of the entity type corresponding to the ghost reference is unique, the unique instance is identified as the third real entity. The value of the entity identifier field is extracted from the data structure of the third real entity, and the value is assigned to the repair identifier variable corresponding to the ghost reference. A mapping relationship between the ghost reference and the unique instance is established, so that the ghost reference obtains a valid identifier pointing to the actual entity in the system, which is used to update the original ghost reference to the correct entity reference in the subsequent replacement steps.

[0079] Here, a unique instance refers to the only entity object in the system's actual entity set that belongs to the entity type corresponding to the ghost reference. A third real entity refers to the actual entity object that is successfully matched through the third-level matching strategy, and this entity is the only instance in the system's actual entity set that belongs to the entity type corresponding to the ghost reference.

[0080] S1047. If the number of instances is not unique, then based on the fourth-level matching strategy, determine whether there is a fourth real entity in the sub-operator name of the entity contained in the actual entity set of the system that corresponds to the value of the ghost reference.

[0081] Specifically, when the third-level matching strategy determines that the number of instances of the entity type corresponding to the ghost reference is not unique, the fourth-level matching strategy is executed. The value of the ghost reference is used as the query condition. Each workflow entity in the actual entity set of the system is traversed. For each workflow entity, the list of its sub-item operator names is obtained. The value of the ghost reference is compared with each operator name in the sub-item operator name list of each workflow entity. If there is a workflow entity whose sub-item operator name list contains an operator name that is exactly the same as the value of the ghost reference, then the workflow entity is determined as the fourth real entity, and the matching process of the fourth-level matching strategy is completed.

[0082] The fourth-level matching strategy refers to a matching method in multi-level degradation matching that performs cross-matching based on the names of operators contained in the workflow. A sub-operator refers to each operator instance orchestrated within a workflow entity, and each sub-operator has a standardized operator name. The fourth real entity refers to the actual entity object successfully matched through the fourth-level matching strategy. This entity is a workflow entity whose sub-operator names are completely identical to the values ​​of the ghost references.

[0083] In practical applications, a common type of illusion exists when AI generates configurations: the AI ​​incorrectly references operator names as workflow names. For example, the AI ​​might generate "image cropping" as a workflow reference, but in reality, "image cropping" is an operator name, not a workflow name. Since operators are usually orchestrated within workflows as components, when the AI ​​incorrectly uses an operator name as a workflow name, the corresponding workflow can be inferred through the inclusion relationship between operators and workflows—the workflow containing that operator is the workflow the AI ​​intended to reference. Therefore, the fourth-level matching strategy utilizes the inclusion relationship between workflows and operators to cross-match the value of the phantom reference with the names of the sub-operators contained in each workflow. When the value of the phantom reference matches the name of a sub-operator in a workflow, that workflow is used as the matching result, thus correcting the erroneous workflow reference into the correct workflow entity.

[0084] S1048. If a fourth real entity exists, then the fourth real entity shall be used as the repair identifier.

[0085] Specifically, when the fourth-level matching strategy successfully matches the fourth real entity, the value of the entity identifier field is extracted from the data structure of the fourth real entity, and the value is assigned to the repair identifier variable corresponding to the ghost reference. This establishes a mapping relationship between the ghost reference and the fourth real entity, so that the ghost reference obtains a valid identifier pointing to the actual workflow entity in the system. This identifier is then used to update the original ghost reference to the correct entity reference in subsequent replacement steps.

[0086] S105. When multiple ghost references match the same real entity, merge the permission items corresponding to the multiple ghost references to obtain the merged permission items.

[0087] Specifically, when multiple phantom references are mapped to the same real entity through multi-level degradation matching, all independent permission items corresponding to these phantom references are retrieved. These permission items may be scattered across different access control lists. An empty permission set is created, and then permission items obtained from each phantom reference are added to it one by one, automatically deduplicating them in the process. Finally, a final permission list containing all source permissions without duplicates is generated; this list is the merged permission set. This merged result is applied to the user's unique real entity, ensuring that regardless of which alias grants permissions, the user ultimately enjoys the complete set of all due permissions, avoiding permission omissions or conflicts.

[0088] In this context, a permission item refers to a set of permissions defined in the backend permission configuration for a specific resource identifier. Each permission item contains at least one permission operation and a corresponding Boolean permission value for each operation. The Boolean permission value indicates whether the permission operation is allowed; true indicates allowed, and false indicates prohibited. A merged permission item refers to a single permission item generated by merging multiple permission items through a logical OR operation. The Boolean permission values ​​for each permission operation in this permission item are the logical OR result of the corresponding Boolean values ​​of the original multiple permission items.

[0089] Based on the above embodiments, as an optional embodiment, for Figure 1 The step S105 shown can be implemented through steps S1051-S1054, which will be explained in detail below.

[0090] S1051. Obtain multiple permission items corresponding to the target ghost reference in the backend permission configuration. Each permission item contains at least one permission operation. The target ghost reference is any ghost reference among multiple ghost references that match the same real entity.

[0091] Specifically, the permission item corresponding to the target ghost reference is located from the backend permission configuration. This target ghost reference is any one of multiple ghost references that match the same real entity. All permission operations and the corresponding boolean permission values ​​contained in the permission item are extracted. At the same time, other ghost references that match the same real entity are traversed, and their corresponding permission items are located and extracted from the backend permission configuration. The permission operations and boolean permission values ​​in each permission item are obtained. All extracted permission items are gathered into a set of permission items to be merged for subsequent permission merging processing.

[0092] Here, a target ghost reference refers to any one of multiple ghost references mapped to the same real entity after multi-level downgrade matching, used to identify the real entity corresponding to the group of ghost references to be merged. Permission operations refer to the specific operation types that users or roles can perform on an entity, including operations such as execute, view results, configure, and delete. Each permission operation corresponds to a Boolean permission value.

[0093] For example, after multi-level degradation matching, both the ghost reference "Image Preprocessing Workflow" and the ghost reference "wf_001" are mapped to the same real entity workflow "wf_001". The target ghost reference is selected as "Image Preprocessing Workflow". The corresponding permission item in the backend permission configuration is obtained. This permission item includes the resource identifier "Image Preprocessing Workflow" and the permission operations: execute = true, view_result = true, configure = false. Simultaneously, the permission item corresponding to the other ghost reference "wf_001" is obtained. This permission item includes the resource identifier "wf_001" and the permission operations: execute = false, view_result = false, configure = true. Both of these permission items are associated with the real entity "wf_001", forming a set of multiple permission items to be merged.

[0094] S1052. Establish an aggregate mapping table with the identifier of the same real entity as the unique key value.

[0095] Specifically, an empty key-value pair storage structure is created as an aggregation mapping table. The identifier of the real entity is obtained from multiple ghost references that match the same real entity. This identifier is used as the unique key value of the aggregation mapping table. An empty permission entry corresponding to this key value is initialized in the aggregation mapping table. This is used to gradually accumulate and update the permission merging result of the real entity during subsequent traversal, ensuring that each real entity identifier in the aggregation mapping table corresponds to only one permission entry.

[0096] The aggregation mapping table is a key-value pair storage structure used to temporarily store intermediate results of permission merging. This structure supports storing data in key-value pair format, with each key corresponding to a value, and keys are unique within the table. A unique key-value pair is a critical field in the aggregation mapping table used to identify and locate permission items; this field cannot appear repeatedly in the table. The same real entity refers to the actual entity object that multiple ghost references jointly map to after multi-level degradation matching; this entity exists in the system's actual entity set. An identifier is a unique identification code assigned by the system to an actual entity, used to identify and locate the entity within the system; it is usually stored in string format.

[0097] For example, after multi-level downgrade matching, both the ghost reference "Image Preprocessing Workflow" and the ghost reference "wf_001" are mapped to the same real entity workflow "wf_001", which is identified as "wf_001". An aggregated mapping table is established with "wf_001" as the unique key. Initially, the value corresponding to the key "wf_001" in the table is empty. When traversing the first permission item, the permission item content is stored in the value corresponding to the key "wf_001"; when traversing the second permission item, the second permission item is logically ORed with the value corresponding to the key "wf_001" and then the value is updated. Finally, the key "wf_001" in the aggregated mapping table corresponds to the merged permission item. If another set of ghost references maps to the real entity "wf_002", another entry is created with "wf_002" as the unique key. The identifiers of different real entities do not interfere with each other in the aggregated mapping table.

[0098] S1053. For the same permission operation, if the permission status of any of the ghost references in the multiple ghost references is allowed, then the permission status after aggregation is set to allowed and written into the aggregation mapping table to overwrite the original permission status, resulting in the aggregation mapping table after union processing.

[0099] Specifically, for the currently being processed permission operation, the system iterates through the permission items corresponding to multiple ghost references that match the same real entity, and sequentially reads the boolean permission value corresponding to the permission operation in each permission item. If the boolean permission value of any permission item is true, the permission status after the permission operation is aggregated is determined to be true, and the true value is written into the permission item entry corresponding to the real entity identifier in the aggregation mapping table, overwriting the original permission status value of the permission operation field. The above traversal, judgment and write overwrite operations are performed sequentially for each permission operation. After processing all permission operations, the aggregation mapping table after union processing is obtained, which can effectively avoid false permission interception caused by phantoms.

[0100] In this context, "same permission operation" refers to a permission operation type common to multiple permission items, including operations such as execute, view results, configure, and delete. Permission status refers to a Boolean permission value, where true indicates permission is allowed and false indicates prohibition; permission means the permission status is true. The aggregated mapping table after union processing is the aggregated mapping table obtained after performing a logical OR operation on all permission operations and writing them into the table. Each real entity identifier's corresponding permission item contains the permission status after taking the union of all permission operations.

[0101] For example, continuing from the previous example, multiple ghost references mapped to the same real entity workflow "wf_001" correspond to two permission items: Permission item A contains "execute" as true, "view_result" as true, and "configure" as false; permission item B contains "execute" as false, "view_result" as false, and "configure" as true. For the permission operation "execute", permission item A has a true permission status, permission item B has a false permission status, and either one is true. After aggregation, the permission status is set to allowed, and the true value is written to the "execute" field of the permission item corresponding to the key "wf_001" in the aggregation mapping table, overwriting the original null value. For the permission operation "view_result", permission item A is true, permission item B is false, and the aggregation result is true, written to the "view_result" field. For the permission operation "configure", permission item A is false, permission item B is true, and the aggregation result is true, written to the "configure" field. After the traversal is complete, the permission entries corresponding to the key "wf_001" in the aggregation map table contain execute, view_result, and configure as true, resulting in the aggregation map table after union processing.

[0102] S1054. Based on the aggregated mapping table after union processing, generate the merged permission items.

[0103] Specifically, the permission entry corresponding to the real entity identifier is extracted from the aggregated mapping table after the union processing. This permission entry already contains the final Boolean permission value after the logical OR operation of each permission operation. This permission entry is output as the merged permission entry to replace the multiple permission entries that were originally scattered across multiple ghost references in the backend permission configuration.

[0104] For example, continuing from the previous example, in the aggregated mapping table after union processing, the permission item corresponding to the key "wf_001" contains "execute" as true, "view_result" as true, and "configure" as true. This permission item is extracted as the merged permission item, which corresponds to the real entity workflow "wf_001" and contains the permission operations "execute" as true, "view_result" as true, and "configure" as true. In the original backend permission configuration, the permission item corresponding to the ghost reference "image preprocessing workflow" contains "execute" as true, "view_result" as true, and "configure" as false, while the permission item corresponding to the ghost reference "wf_001" contains "execute" as false, "view_result" as false, and "configure" as true. Both of these permission items point to the same real entity "wf_001". These two permission items are replaced with the merged permission item, which contains "execute" as true, "view_result" as true, and "configure" as true. If the aggregated mapping table also contains a permission item corresponding to the key "wf_002", then the merged permission items corresponding to the real entities are extracted and generated separately.

[0105] Through the above embodiments, multiple permission items corresponding to multiple ghost references are merged into one permission item, realizing the automatic deduplication of duplicate permission configurations caused by AI due to multiple name illusions. The merged permission item retains all allowed permission operations in the original multiple permission items, avoiding permission loss due to simple overwriting or discarding. At the same time, the merging operation reduces redundant entries in the backend permission configuration, making the repaired configuration more concise and clear, reducing configuration complexity and potential conflict risks.

[0106] S106. Replace the ghost reference with the corresponding repair identifier to obtain the repaired ghost reference, and update the permission item corresponding to the repaired ghost reference with the corresponding merged permission item to obtain the repaired backend permission configuration.

[0107] Specifically, in the backend permission configuration, locate the field containing the ghost reference, replace the original value of the field with the corresponding repair identifier, complete the ghost reference replacement operation, and obtain the repaired ghost reference; locate the permission item corresponding to the repaired ghost reference, replace the content of the permission item with the corresponding merged permission item, overwrite the original permission operation boolean permission value, and complete the permission item update operation; perform the above replacement and update operations sequentially on all ghost references that need to be processed in the backend permission configuration to obtain the repaired backend permission configuration.

[0108] In this context, "repaired ghost references" refers to resource identifiers that, after the replacement operation, originally pointed to non-existent entities but have now been updated to point to real entities. "Repaired backend permission configuration" refers to the backend permission configuration obtained after completing ghost reference replacement and permission item updates. In this configuration, all resource identifiers point to actual entities existing in the system, and each real entity retains only one permission item.

[0109] For example, continuing from the previous example, the backend permission configuration includes a ghost reference "Image Preprocessing Workflow" and its corresponding permission item A, which contains execute as true, view_result as true, and configure as false, as well as a ghost reference "wf_001" and its corresponding permission item B, which contains execute as false, view_result as false, and configure as true. Through multi-level degradation matching, the repair identifier for the ghost reference "Image Preprocessing Workflow" is "wf_001", and the repair identifier for the ghost reference "wf_001" is also "wf_001". The merged permission items contain execute as true, view_result as true, and configure as true. Replacing the ghost reference "Image Preprocessing Workflow" with the repair identifier "wf_001" yields the repaired ghost reference; replacing the ghost reference "wf_001" with the repair identifier "wf_001" yields the repaired ghost reference. Update the permission entries corresponding to the two repaired ghost references to the merged permission entries. This means merging the two separate entries corresponding to permission entry A and permission entry B into one entry. This entry contains the resource identifier "wf_001" and the permission values ​​"execute," "view_result," and "configure" are all true. After the replacement and update, the repaired backend permission configuration is obtained. In this configuration, workflow "wf_001" retains only one permission entry, and the resource identifier points to the actual workflow entity existing in the system.

[0110] S107. Based on the repaired backend permission configuration and frontend verification reference data, perform validity verification on the frontend components and cross-layer binding information respectively, and obtain the frontend component verification result and the frontend cross-layer binding verification result.

[0111] Specifically, component registration data and deployed endpoint data are obtained from the front-end verification reference data. For each front-end component in the front-end design configuration, the existence of the component and the compatibility of the attribute configuration with the expected attribute types declared in the component metadata are verified based on the component registration data, and a front-end component verification result is generated. For each cross-layer binding information in the front-end design configuration, the existence and reachability of the bound back-end API endpoint are verified based on the deployed endpoint data, and the compatibility of the endpoint output data format with the expected input data structure of the component is compared, and a front-end cross-layer binding verification result is generated.

[0112] Specifically, the front-end component validation result refers to a summary of the pass status and detailed information for front-end component existence validation and attribute type compatibility validation. The front-end cross-layer binding validation result refers to a summary of the pass status and detailed information for endpoint reachability validation and data format compatibility validation.

[0113] Based on the above embodiments, as an optional embodiment, for Figure 1 The step S107 shown can be implemented through steps S1071-S1078, which will be explained in detail below.

[0114] S1071. If a front-end component exists in the component registration data, then mark the component existence verification result as existing.

[0115] Specifically, the system uses the identifier of the front-end component as an index to perform a precise query in the component registration data. If a component record that is exactly the same as the identifier is found, the status field of the component existence verification result is set to an existence value, indicating that the front-end component has been registered in the system and can be used for subsequent attribute type compatibility verification.

[0116] Among them, the component existence verification result refers to the status information of the front-end component's existence verification, which is used to record whether the front-end component has been registered in the system.

[0117] S1072. If the front-end component does not exist in the component registration data, query the preset component source; if the front-end component exists in the preset component source, mark the component existence verification result as pending installation; if the front-end component does not exist in the preset component source, mark the component existence verification result as non-existent.

[0118] Specifically, if a matching record is not found in the component registration data after searching using the identifier of the front-end component as an index, the search will then proceed to the preset component source with the same identifier. If a component package or resource record that is exactly the same as the identifier is found in the preset component source, the status field of the component existence verification result will be set to the value of "to be installed", indicating that the front-end component can be obtained from the preset component source but has not yet been registered; if no matching record is found in the preset component source, the status field of the component existence verification result will be set to the value of "not found", indicating that the front-end component cannot be found in any available source.

[0119] Among them, the preset component source refers to the public or private component repository configured by the system to obtain front-end components. It serves as a supplementary source of component registration data and is used to determine whether unregistered components can be obtained.

[0120] S1073. When the component existence verification result is "existing" or "to be installed", obtain the preset component metadata corresponding to the front-end component that passed the component existence verification, compare the value type of each attribute in the attribute configuration of the front-end component with the expected attribute type in the preset component metadata, and obtain the attribute type compatibility verification result.

[0121] Specifically, the status field of the component existence verification result is read. If the status is "existing" or "to be installed", the corresponding preset component metadata file is obtained from the component registration data or preset component source. The attribute names and expected attribute types declared in the metadata file are parsed. The attribute configurations of the front-end component in the front-end design configuration are traversed. The actual value type of each attribute is extracted. The actual value type is compared with the expected attribute type declared in the metadata item by item to determine whether they match or conform to the type compatibility rules. The comparison result of each attribute is recorded and the attribute type compatibility verification result is generated.

[0122] The preset component metadata refers to the descriptive configuration file of the front-end component, usually stored in JSON format, declaring information such as component attribute definitions, attribute types, default values, and required constraints. Attribute configuration refers to the set of attribute values ​​set for a specific front-end component instance in the front-end design configuration, stored in key-value pairs. Value type refers to the actual data type of the attribute value in the attribute configuration, including strings, numbers, booleans, arrays, and objects. Expected attribute type refers to the data type that the attribute should satisfy as declared in the preset component metadata, including basic types, enumeration types, union types, and composite types. Attribute type compatibility verification result is a summary of the pass status and detailed information of attribute type compatibility verification, used to record the type matching status of each attribute.

[0123] S1074. Generate front-end component verification results based on component existence verification results and attribute type compatibility verification results.

[0124] Specifically, the status field of the component existence verification result is integrated with the detailed record of the attribute type compatibility verification result. Using the identifier of the front-end component as the primary key, the existence status, attribute type compatibility status, and detailed comparison of each attribute are combined into a unified data structure to generate the complete verification result of the front-end component, which is used to generate the subsequent comprehensive verification report.

[0125] S1075. Extract the backend API endpoint bound in the attribute configuration, query whether the backend API endpoint exists based on the deployed endpoint data, and if it exists, send an HTTP request to the backend API endpoint to verify the endpoint reachability and obtain the endpoint reachability verification result.

[0126] Specifically, the attribute values ​​of the backend API endpoints are identified and extracted from the attribute configuration of the frontend components to obtain the endpoint routing address string. The routing address is used as an index to perform a precise query in the deployed endpoint data. If a matching endpoint record is found, the endpoint is determined to exist. An HTTP HEAD request is then sent to the routing address. After receiving the response, the returned status code is checked. If the status code is 2xx or 405, the endpoint is determined to be reachable. If the status code is other values ​​or the request times out, the endpoint is determined to be unreachable. An endpoint reachability verification result is generated based on the results of the existence and reachability verification.

[0127] An HTTP request is a request sent to an endpoint using the HEAD method to verify the endpoint's reachability without obtaining the complete response content.

[0128] S1076. Obtain the output data format description of the backend API endpoint and the expected input data structure of the frontend component.

[0129] Specifically, the output data format description field corresponding to the backend API endpoint is read from the deployed endpoint data. If the description is not stored in the deployed endpoint data, a sampling HTTP request is sent to the endpoint, and the structure of the returned data is parsed from the response body to infer and generate the output data format description. At the same time, the expected input data structure declaration of the component is read from the preset component metadata of the frontend component, and the list of required fields, the list of optional fields, and the type definition of each field are extracted. The obtained output data format description and expected input data structure are used as input for subsequent comparison operations.

[0130] The output data format description refers to the structural definition of the data returned when the backend API endpoint is called. It is described in JSON Schema or a similar format and includes information such as field names, field types, whether a field is required, and the nesting relationship between fields. The expected input data structure refers to the data format expected by the frontend component during its design, which guides the component on how to parse and render the incoming data.

[0131] S1077. When a required field in the expected input data structure is missing in the output data format description, the cross-layer binding relationship between the front-end component and the back-end API endpoint is marked as data structure incompatibility, and the data format compatibility verification result is obtained.

[0132] Specifically, the system iterates through the list of required fields in the expected input data structure. For each required field, it checks if a field with the exact same name exists in the returned field list of the output data format description. If any required field is not found in the output data format description, the cross-level binding relationship is marked as data structure incompatibility, and the missing field name is recorded. If all required fields exist, the system further compares whether the field types are compatible. If type incompatibility exists, it is also marked as data structure incompatibility, and the incompatible field information is recorded. If all required fields exist and their types are compatible, the cross-level binding relationship is marked as data structure compatible, and a data format compatibility verification result is generated based on the marking result.

[0133] Among them, required fields refer to data fields necessary for the rendering of the front-end component; if these fields are missing, the component will not function correctly. Cross-layer binding relationships refer to the associations formed between the back-end API endpoints bound in the front-end component's property configuration. Data structure incompatibility means that the data format returned by the back-end API endpoint cannot meet the data requirements of the front-end component. Data format compatibility verification result refers to the pass / fail status and detailed information of the data structure compatibility verification, used to record the data structure compatibility status of cross-layer bindings.

[0134] S1078. Use the endpoint reachability verification result and the data format compatibility verification result as the cross-layer binding verification result.

[0135] Specifically, the endpoint reachability verification result and the data format compatibility verification result are integrated as the cross-layer binding verification result. The endpoint reachability verification result refers to the record of the existence and reachability status of the backend API endpoint, including three statuses: not deployed, reachable, and unreachable. The data format compatibility verification result refers to the record of the data format compatibility status between the frontend component and the backend API endpoint, including two statuses: compatible and incompatible. In the incompatible status, specific information about missing field names or incompatible field names is attached. The cross-layer binding verification result is a comprehensive verification output formed by combining the endpoint reachability verification result and the data format compatibility verification result. It is used to record the overall validity status of the backend API endpoints bound in the frontend component attribute configuration, and serves as a component of the subsequent comprehensive verification and repair results.

[0136] S108. Based on the front-end component validation results, the front-end cross-layer binding validation results, and the repaired back-end permission configuration, output the validation and repair results of the initial full-stack system configuration.

[0137] Specifically, the front-end component verification results, front-end cross-layer binding verification results, and the repaired back-end permission configuration are summarized and integrated. The data is organized according to the preset report format to generate verification and repair results that include back-end permission configuration repair details, front-end component verification status list, cross-layer binding verification status list, and overall compliance conclusion. The results are output in a structured data format for front-end interface rendering or downstream system consumption.

[0138] The verification and repair results refer to the comprehensive output obtained after performing integrity verification and automatic repair on the initial full-stack system configuration. This includes repair details of backend permission configuration, verification status of frontend components, verification status of cross-layer binding, and overall compliance conclusions.

[0139] For example, after processing, the initial full-stack system configuration yields a repaired backend permission configuration. The permission items for workflow "wf_001" are merged into "execute true," "view_result true," and "configure true," and all resource identifiers point to actual existing entities. Frontend component validation results show that component "qt-data-table" exists and all attribute type compatibility passes; component "qt-chart-3d" exists but is pending installation, and attribute type compatibility is not validated due to the component not being registered. Frontend cross-layer binding validation results show that endpoint " / api / event / execute / wf_001" is reachable and data format compatibility is compatible; endpoint " / api / event / execute / wf_002" is unreachable and data format compatibility is not validated. The above results are summarized and integrated to generate a verification and repair result. This result includes the repaired backend permission configuration content, a list of frontend component verification reports, a list of cross-layer binding verification reports, and an overall compliance conclusion: the backend permission configuration has been repaired; some frontend components require user intervention due to pending installations; some cross-layer bindings have unreachable endpoints requiring service status checks; and the overall verification process has passed. The generated verification and repair result is output in structured JSON format for frontend interface rendering or for consumption by downstream systems.

[0140] Through the above embodiments, a unified presentation of the three-layer verification and repair results of the full-stack system configuration is achieved. The repair results of the backend permission configuration show the automatic repair of ghost references in the AI-generated configuration. The frontend component verification results show the existence of components and the validity of attribute configurations. The cross-layer binding verification results show the reliability of the association between the frontend and the backend. The three-layer results together constitute a comprehensive assessment of the integrity and consistency of the full-stack system configuration, providing users with a clear configuration quality report and subsequent processing suggestions.

[0141] Based on the above embodiments, as an optional embodiment, see [link to embodiment]. Figure 2 ,against Figure 1 The verification and automatic repair method for the full-stack system shown may also include Figure 2 Steps S301-S303 are explained in detail below.

[0142] S301. Obtain the client's request text and determine the operation mode corresponding to the request text through a preset intent keyword model.

[0143] Specifically, the system receives the request text sent by the client and matches it against the set of verification mode trigger words and the set of repair mode trigger words defined in the preset intent keyword model. It iterates through the trigger word list. If the request text contains a verification mode trigger word but not a repair mode trigger word, the operation mode is set to read-only verification mode. If the request text contains a repair mode trigger word, the operation mode is set to write repair mode. If both types of trigger words are contained, the final operation mode is determined according to the preset priority rules. If no trigger word is matched, the default is set to read-only verification mode.

[0144] Here, "client" refers to the terminal device or application interface through which the user interacts with the system, used to receive user input and display processing results. "Request text" refers to the natural language instructions or operational intent descriptions entered by the user through the client interface, carrying the user's operational needs in text form. "Preset intent keyword model" refers to a pre-built set of keyword matching rules used to identify user intent, determining the user's intent through exact or fuzzy keyword matching. "Operation mode" refers to the system's behavioral pattern when performing verification and repair operations, including at least two modes: read-only verification mode and write repair mode.

[0145] S302. If the operation mode is read-only verification mode, then disable the modification execution tool, and generate and output a text verification report with a three-level classification structure based on the front-end component verification results, the front-end cross-layer binding verification results, and the back-end permission configuration that has not yet been replaced and repaired.

[0146] Specifically, when the operation mode is detected as read-only verification mode, the disable interface of the modification execution tool is called to prevent any configuration write operations from being executed, ensuring that the backend permission configuration is not modified throughout the verification process. All error, warning, and suggestion level verification information is extracted from the frontend component verification results. The corresponding three-level classification information is extracted from the frontend cross-layer binding verification results. Ghost reference related verification issues are extracted from the backend permission configuration that has not yet replaced the repair identifier. All extracted information is classified and summarized according to three levels: error, warning, and suggestion. The error level is used to record items that fail verification and cannot be automatically repaired. The warning level is used to record items that fail verification but have repair suggestions. The suggestion level is used to record optimization suggestions. The classified and summarized results are formatted into a well-structured text report according to a preset text template, and the text verification report with this three-level classification structure is output.

[0147] In this context, read-only verification mode refers to a system behavior mode that only performs verification operations without making any configuration modifications. Modification execution tools refer to functional modules used to perform configuration modification operations, including write operation interfaces such as ghost reference replacement and permission item updates. Backend permission configurations without replaced / repaired identifiers refer to the original backend permission configurations that have not undergone ghost reference replacement and permission item merging. A three-level categorized text verification report refers to verification result text organized into three levels: error, warning, and suggestion. The error level corresponds to serious issues, the warning level to issues requiring attention, and the suggestion level to optimization recommendations.

[0148] Through the above embodiments, read-only verification of the configuration and hierarchical presentation of problems are achieved. Disabling modification execution tools ensures the security of the verification process and avoids incorrect modification of the configuration due to accidental operation. The three-level classification report organizes the verification results according to the priority of errors, warnings and suggestions. The error category identifies serious problems that must be dealt with, the warning category identifies problems that can be optimized and provides repair suggestions, and the suggestion category provides improvement suggestions, so that users can clearly understand the overall status of the configuration and take targeted handling measures accordingly.

[0149] S303. If the operation mode is write repair mode, the ghost reference in the backend permission configuration is replaced with the repair identifier by modifying the execution tool, and the repaired backend permission configuration is output.

[0150] Specifically, when the operation mode is detected as write repair mode, the enable interface of the modification execution tool is called to allow configuration write operations. The list of ghost references to be replaced and their corresponding repair identifiers are obtained from the mapping relationship between ghost references and repair identifiers. The list is traversed, and for each ghost reference, its field in the backend permission configuration is located. The original value of the field is replaced with the corresponding repair identifier, and the permission item corresponding to the ghost reference is updated to the merged permission item. After all replacement and update operations are completed, the repaired backend permission configuration is output in a structured data format for persistent storage or use by downstream systems.

[0151] The write-repair mode refers to the behavior of the system performing verification and automatically repairing when a problem is detected, and persistently storing the modified results.

[0152] Based on the above embodiments, as an optional embodiment, see [link to embodiment]. Figure 2 ,exist Figure 1 Following step S108, the following steps may also be included: Figure 2 Steps S401-S405 are explained in detail below.

[0153] S401. Establish a backend layer event listener for the deployed full-stack system, and capture dynamic configuration change events of the backend API endpoints through the backend layer event listener.

[0154] Specifically, a backend-layer event listener service is deployed and started in the backend system. This listener runs as a resident process and establishes a connection with the backend system by subscribing to the backend system's configuration change message queue or registering a callback interface. When configuration changes occur in the backend system, such as endpoint routing address changes, deletion of backend workflow entities, or deletion of backend operator entities, the backend system publishes a dynamic configuration change event to the message queue. The backend-layer event listener receives the event in real time and extracts information such as the event type, the identifier of the affected target entity, the routing address before the change, and the routing address after the change from the event payload, thus completing the capture of the dynamic configuration change event.

[0155] In this context, a deployed full-stack system refers to a full-stack application system that has been deployed and is running, including backend services and frontend applications. A backend-layer event listener is a listening service deployed in the backend system to monitor backend configuration changes; it runs as a persistent process or a callback interface. Dynamic configuration change events refer to configuration changes that occur at backend API endpoints during runtime, including events such as endpoint routing address changes, deletion of the corresponding backend workflow entity, and deletion of the corresponding operator entity.

[0156] S402. When a dynamic configuration change event is captured, parse the source endpoint routing address affected by the configuration change event.

[0157] Specifically, the data in the event payload is decoded, typically from JSON or YAML format into an in-memory object. Then, by recognizing the naming conventions or path structures of configuration items (e.g., configuration key names containing keywords like `service.registry` or `routing.endpoints`), the resolver determines whether the change is related to service registration, service discovery, or routing rules. If a relevant change is confirmed, the resolver precisely compares the old and new configuration data to determine the specific content of the change. For example, in a list of service instances, it might determine whether an instance has been added, deleted, or its metadata (such as weight) has changed. Finally, based on the context of the change, the resolver extracts the key network identifier from the new configuration data. This identifier is the source endpoint routing address, which is usually represented as an IP address:port number, or a service name or domain name that can be resolved to this format by the system. For example, if the event is a notification of a service instance coming online, the resolver will extract the IP address and port of this new instance from the new configuration as the final resolution result. This process successfully transforms an abstract configuration change event into a specific and actionable network address, providing a precise target for subsequent dynamic adjustment operations such as routing table updates, load balancer reloads, or connection pool refreshes.

[0158] The source endpoint routing address refers to the original routing address of the changed backend API endpoint before it was modified, and is used as the query key value for reverse dependency scanning.

[0159] S403. Traverse the cross-layer binding information, extract the attribute configuration of the front-end components from the cross-layer binding information, and filter out the associated front-end components that are bound to the source endpoint route address in the attribute configuration.

[0160] Specifically, the system iterates through the list of cross-layer binding information in the front-end design configuration. For each cross-layer binding information, it extracts the attribute value of the bound back-end API endpoint from the front-end component attribute configuration, obtains the endpoint routing address string referenced by the cross-layer binding information, and compares this string precisely with the parsed source endpoint routing address. If they are completely identical, the front-end component corresponding to the cross-layer binding information is selected as an associated front-end component, and the identifier of the front-end component and the cross-layer binding information are recorded in the associated component list. After completing the traversal of all cross-layer binding information, the system outputs the filtered list of associated front-end components.

[0161] In this context, attribute configuration refers to the set of attribute values ​​set for a specific front-end component instance in the front-end design configuration, stored in key-value pairs; retrieval refers to the process of obtaining the attribute values ​​bound to the back-end API endpoint from the attribute configuration. Associated front-end components are those whose back-end API endpoints bound in their attribute configurations match the changed source endpoint routing address.

[0162] S404. If the dynamic configuration change event is an endpoint route address change, then mark the cross-layer binding status of the associated front-end component as an outdated binding and generate an automatic repair suggestion to update the outdated binding to the changed route address.

[0163] Specifically, when a dynamic configuration change event of endpoint route address change is detected, the system iterates through the filtered list of associated front-end components. For each associated front-end component, the status field in its cross-layer binding information is set to the old binding value, and the currently bound endpoint route address is recorded as the old address. The value of the changed route address field is extracted from the dynamic configuration change event, and an automatic repair suggestion is generated for each associated front-end component. This suggestion includes the component identifier, the old endpoint route address, the new endpoint route address, and an operation description for updating the binding address in the attribute configuration from the old address to the new address. The generated automatic repair suggestion is then output to the user interface or the repair execution module.

[0164] Among these, endpoint route address change refers to an event type where the access path of the backend API endpoint is modified. Cross-layer binding status refers to the validity status of the association between the frontend component and the backend API endpoint. Deprecated binding means that the backend API endpoint route address bound in the frontend component's property configuration has changed, but the frontend design configuration still uses the old address before the change; this binding relationship is outdated but can be repaired through automatic updates. Modified route address refers to the new address after the endpoint route address change, extracted from the dynamic configuration change event.

[0165] Through the above embodiments, by marking the cross-layer binding status of the associated front-end components triggered by the endpoint routing address change event as outdated binding and generating automatic repair suggestions to update to the new routing address, proactive response and repair guidance for backend endpoint address changes are achieved. The outdated binding status clearly identifies the cross-layer binding relationships that need to be updated, and the automatic repair suggestions provide precise update targets, avoiding the problem that the front-end components cannot call the backend services normally due to endpoint address changes. The work that originally required manual investigation and repair is transformed into automated detection and clear suggestions, improving the efficiency and accuracy of system maintenance.

[0166] S405. If the dynamic configuration change event is that the backend workflow entity or operator entity is deleted, the cross-layer binding status of the associated frontend component will be marked as broken binding, blocking automatic repair, and generating a cross-layer topology blocking work order with error breakpoints.

[0167] Specifically, when a dynamic configuration change event is detected where the event type is "backend workflow entity deleted" or "backend operator entity deleted," the system iterates through the filtered list of associated frontend components. For each associated frontend component, the status field in its cross-layer binding information is set to the broken binding value, and the blocking interface of the modification execution tool is called to prevent any automatic repair operation from being performed on the broken binding. The identifier of the deleted entity is extracted from the dynamic configuration change event, and a cross-layer topology blocking work order is generated for each associated frontend component. This work order includes the component identifier, the identifier of the deleted entity, the endpoint routing address of the broken binding, and error breakpoint information. The error breakpoint information marks the specific location and cause of the break in the cross-layer link. The generated work order is output to the user interface or the operation and maintenance system for manual intervention.

[0168] Here, "backend workflow entity deletion" refers to the event type where a workflow entity is removed from the system; "backend operator entity deletion" refers to the event type where an operator entity is removed from the system. "Broken binding" means that the backend workflow entity or operator entity corresponding to the backend API endpoint bound in the frontend component's property configuration has been deleted, and this binding relationship cannot be repaired through automatic updates. "Cross-layer topology blocking work order" is a fault report that records detailed information about broken bindings, used to notify users to intervene. "Error breakpoint" refers to information used to mark the location of a break in a cross-layer link, including the broken component identifier, the missing entity identifier, and the specific location of the break.

[0169] Through the above embodiments, accurate identification and manual intervention guidance for unrecoverable cross-layer binding failures are achieved. The broken binding status clearly identifies cross-layer binding relationships that cannot be automatically repaired due to the absence of backend entities. Blocking automatic repair avoids invalid configurations caused by blind updates. The cross-layer topology blocking work order provides complete fault information, enabling users to quickly locate problems and take appropriate measures, such as reconfiguring frontend components to point to other available endpoints or restoring deleted backend entities.

[0170] The following describes the verification and automatic repair system of the full-stack system in the embodiments of this invention from the perspective of hardware processing. Please refer to [link / reference needed]. Figure 3 , Figure 3 This is a schematic diagram of the structure of a full-stack system verification and automatic repair system provided in an embodiment of this application.

[0171] It should be noted that, Figure 3 The structure of the full-stack system verification and automatic repair system shown is merely an example and should not impose any limitations on the functionality and scope of application of the embodiments of this application.

[0172] like Figure 3As shown, the full-stack system's verification and automatic repair system includes a central processing unit 501, which can perform various appropriate actions and processes based on the program stored in the read-only memory 502 or the program loaded from the storage section 508 into the random access memory 503, such as executing the methods described in the above embodiments. The random access memory 503 also stores various programs and data required for system operation. The central processing unit 501, the read-only memory 502, and the random access memory 503 are interconnected via a bus 504. An input / output interface 505 is also connected to the bus 504.

[0173] The following components are connected to the input / output interface 505: an input section 506 including audio input devices, push-button switches, etc.; an output section 507 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the input / output interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 510 as needed so that computer programs read from it can be installed into the storage section 508 as needed.

[0174] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by central processing unit 501, it performs the various functions defined in the present invention. It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0175] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0176] Specifically, the full-stack system verification and automatic repair system of this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the full-stack system verification and automatic repair method provided in the above embodiment.

[0177] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the verification and automatic repair system of the full-stack system described in the above embodiments; or it may exist independently and not assembled into the verification and automatic repair system of the full-stack system. The storage medium carries one or more computer programs, which, when executed by a processor of the verification and automatic repair system of the full-stack system, cause the verification and automatic repair system of the full-stack system to implement the verification and automatic repair method of the full-stack system provided in the above embodiments.

[0178] The above description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A method for verification and automatic repair of a full-stack system, characterized in that, include: Obtain the initial full-stack system configuration, the actual system entity set, and the front-end verification reference data. The initial full-stack system configuration includes backend permission configuration and front-end design configuration. The backend permission configuration contains at least one resource identifier. The front-end design configuration contains front-end components and cross-layer binding information for binding backend API endpoints. The initial full-stack system configuration is pre-generated by the large language model. Each of the resource identifiers is compared with the actual entities in the system's actual entity set; When the resource identifier is inconsistent with all of the actual entities, the resource identifier is marked as a ghost reference; Based on the actual entity set of the system, the ghost reference is subjected to multi-level downgrade matching in a preset matching order until a real entity is successfully matched in the actual entity set of the system, and the real entity is used as the repair identifier of the ghost reference. When multiple ghost references match the same real entity, the permission items corresponding to the multiple ghost references are merged to obtain the merged permission items; Replace the ghost reference with the corresponding repair identifier to obtain the repaired ghost reference, and update the permission item corresponding to the repaired ghost reference with the corresponding merged permission item to obtain the repaired backend permission configuration. Based on the repaired backend permission configuration and the frontend verification reference data, the validity of the frontend component and the cross-layer binding information are verified respectively to obtain the frontend component verification result and the frontend cross-layer binding verification result. Based on the front-end component verification results, the front-end cross-layer binding verification results, and the repaired back-end permission configuration, the verification and repair results of the initial full-stack system configuration are output.

2. The method according to claim 1, characterized in that, The process of performing multi-level downgrade matching on the phantom references based on the actual entity set of the system, according to a preset matching order, until a real entity is successfully matched in the actual entity set of the system, and using the real entity as the repair identifier for the phantom references, includes: Based on the first-level matching strategy, it is determined whether there is a first real entity in the actual entity set of the system whose entity name corresponds to the value of the ghost reference; If the first real entity exists, then the first real entity is used as the repair identifier for the ghost reference; If the first real entity does not exist, then based on the second-level matching strategy, it is determined whether there is a second real entity in the actual entity set of the system that corresponds to the value of the ghost reference; If the second real entity exists, then the second real entity is used as the repair identifier; If the second real entity does not exist, then based on the third-level matching strategy, it is determined whether the number of instances belonging to the entity type corresponding to the ghost reference in the actual entity set of the system is unique; If the number of instances is unique, then the ghost reference is mapped to the unique instance as the third real entity, and the third real entity is used as the repair identifier; If the number of instances is not unique, then based on the fourth-level matching strategy, it is determined whether there is a fourth real entity in the sub-item operator name contained in the entity of the actual entity set of the system that corresponds to the value of the ghost reference. If the fourth real entity exists, then the fourth real entity will be used as the repair identifier.

3. The method according to claim 1, characterized in that, When multiple ghost references match the same real entity, the permission items corresponding to the multiple ghost references are merged to obtain the merged permission items, including: Obtain multiple permission items corresponding to the target ghost reference in the backend permission configuration, each permission item contains at least one permission operation, and the target ghost reference is any ghost reference among multiple ghost references that match the same real entity; Establish an aggregated mapping table with the identifier of the same real entity as the unique key value; For the same permission operation, if the permission status of the permission operation of any of the multiple ghost references is allowed, then the permission status after aggregation is set to allowed and written into the aggregation mapping table to overwrite the original permission status, resulting in the aggregation mapping table after union processing. Based on the aggregated mapping table after the union processing, merged permission items are generated.

4. The method according to claim 1, characterized in that, Based on the front-end verification reference data, the validity of the front-end component and the cross-layer binding information are verified respectively to obtain the front-end component verification result and the front-end cross-layer binding verification result, including: If the front-end component exists in the component registration data, then the component existence verification result is marked as existing; If the front-end component is not found in the component registration data, a preset component source is queried; if the front-end component exists in the preset component source, the component existence verification result is marked as pending installation; if the front-end component is not found in the preset component source, the component existence verification result is marked as non-existent. When the component existence verification result is "existing" or "to be installed", the preset component metadata corresponding to the front-end component that passed the component existence verification is obtained. The value type of each attribute in the attribute configuration of the front-end component is compared with the expected attribute type in the preset component metadata to obtain the attribute type compatibility verification result. Based on the component existence verification result and the attribute type compatibility verification result, a front-end component verification result is generated. Extract the backend API endpoint bound in the attribute configuration, query whether the backend API endpoint exists based on the deployed endpoint data, and if it exists, send an HTTP request to the backend API endpoint to verify the endpoint reachability and obtain the endpoint reachability verification result. Obtain the output data format description of the backend API endpoint and the expected input data structure of the frontend component; When a required field in the expected input data structure is missing in the output data format description, the cross-layer binding relationship between the front-end component and the back-end API endpoint is marked as data structure incompatibility, and a data format compatibility verification result is obtained. The endpoint reachability verification result and the data format compatibility verification result are used as the cross-layer binding verification result.

5. The method according to claim 1, characterized in that, The method further includes: Obtain the client's request text and determine the operation mode corresponding to the request text through a preset intent keyword model; If the operation mode is read-only verification mode, then the modification execution tool is disabled, and a text verification report with a three-level classification structure is generated and output based on the front-end component verification result, the front-end cross-layer binding verification result, and the back-end permission configuration that has not yet replaced the repair identifier. If the operation mode is write repair mode, the ghost reference in the backend permission configuration is replaced with the repair identifier by the modification execution tool, and the repaired backend permission configuration is output.

6. The method according to claim 1, characterized in that, Before obtaining the initial full-stack system configuration, the actual system entity set, and the front-end verification reference data, the method further includes: The actual entity set of the monitoring system identifies the actual backend workflow entities and operator entities in the current system; Extract standardized entity names from the backend workflow entity and the operator entity to construct a structured authoritative glossary of names; According to the preset prompt word guidance template, the authoritative name vocabulary is converted into name constraint information with exclusive constraint rules; The name constraint information is appended to the end of the system prompt word of the large language model, and the knowledge is anchored to the large language model using the context window to obtain the knowledge-anchored large language model. The configuration generation task is performed by the knowledge-anchored large language model. When the knowledge-anchored large language model outputs the initial full-stack system configuration, the generation space of resource identifiers in the initial full-stack system configuration is restricted to the range of the name constraint information, so as to reduce the probability of illusion in the initial full-stack system configuration.

7. The method according to claim 1, characterized in that, After outputting the verification and repair results of the initial full-stack system configuration, the method further includes: Establish a backend layer event listener for the deployed full-stack system, and capture dynamic configuration change events of the backend API endpoints through the backend layer event listener; When the dynamic configuration change event is captured, the source endpoint routing address affected by the configuration change event is parsed; Traverse the cross-layer binding information, extract the attribute configuration of the front-end component from the cross-layer binding information, and filter out the associated front-end components in the attribute configuration that are bound to the source endpoint route address; If the dynamic configuration change event is an endpoint route address change, then the cross-layer binding status of the associated front-end component is marked as an outdated binding, and an automatic repair suggestion to update the outdated binding to the changed route address is generated; If the dynamic configuration change event is the deletion of a backend workflow entity or operator entity, the cross-layer binding status of the associated frontend component is marked as a broken binding, automatic repair is blocked, and a cross-layer topology blocking work order with error breakpoints is generated.

8. A verification and automatic repair system for a full-stack system, characterized in that, The full-stack system verification and automatic repair system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to cause the full-stack system verification and automatic repair system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is executed on the full-stack system's verification and automatic repair system, the full-stack system's verification and automatic repair system performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the full-stack system's verification and automatic repair system, the full-stack system's verification and automatic repair system performs the method as described in any one of claims 1-7.

Images