Code and non-code resource bidirectional mapping and consistency maintenance method and system

Abstract

The application relates to the technical field of computer data processing, and discloses a code and non-code resource bidirectional mapping and consistency maintenance method and system, which can effectively decouple tasks and codes, and can maintain a strong semantic association and an automatic synchronization mechanism between the tasks and the codes. The method stores source codes and task descriptions in first and second storage spaces which are physically independent and logically associated by configuration, generates a globally unique association identifier, and realizes cross-space entity mapping through metadata marking. An automatic collaborative engine is configured to monitor changes in real time, and trigger an intelligent semantic processing module to perform cross analysis. Task constraint conditions are analyzed to dynamically generate verification logic in the first storage space, or code change characteristics are analyzed to automatically generate structured knowledge objects in the second storage space.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer data processing, in particular to a full-life-cycle data correlation, state synchronization and consistency checking technology for heterogeneous data storage sources in a distributed software development environment. BACKGROUND

[0002] With the increasing scale and complexity of software development, modern software engineering puts forward higher requirements for collaboration efficiency and quality management. In the existing software development process, two core dimensions of management are usually involved: one is the version control and building of source code, usually hosted on a code hosting platform (such as GitHub, GitLab, etc.); the other is the management of task requirements, design documents and project progress, usually relying on project management tools or as document files.

[0003] Currently, the mainstream development mode adopts a "single repository strategy" or a loosely coupled architecture of code and documents. In the single repository mode, source code, build scripts, requirement documents and various evaluation data are usually mixed and stored in the same version control repository. Although this approach centralizes resources to some extent, it has many defects in actual application.

[0004] Firstly, the coupling degree of task management and code development is too high. Due to the mixed storage of non-technical requirement documents and highly technical source code, it is difficult for non-technical members such as product managers and testers to directly participate in the task flow and confirmation, increasing the collaboration threshold. At the same time, a large number of code files often obscure the key task context, making it difficult to audit the task closed loop.

[0005] Secondly, there is a "semantic gap" between the requirement documents and the code implementation. In existing technologies, requirement documents are only used as static reference materials for people to read. For example, the document specifies that the "application programming interface (API) response time should be less than 200ms", but this constraint condition cannot be directly understood and executed by the build system. This leads to the phenomenon of "document rot": as the code iterates, the document often lags behind the implementation and cannot play a real constraint role.

[0006] Thirdly, there is a lack of automatic experience accumulation and knowledge reuse mechanism. Existing development processes widely use continuous integration / continuous deployment processes to automate building and publishing, but these processes mainly focus on the compilation and deployment status of the code. The high-value knowledge generated during the development process, such as successful experience, troubleshooting paths and architecture decisions, is often scattered in the sparse annotations of commit records or merge requests, lacking systematic collection and structured storage, resulting in the inability of subsequent projects to quickly reuse existing experience and the frequent occurrence of repeated mistakes. SUMMARY

[0007] The application provides a code and non-code resource bidirectional mapping and consistency maintenance method and system to solve the technical problem of how to establish a mechanism that can effectively decouple tasks and codes while maintaining strong semantic association and automatic synchronization between the two.

[0008] The application discloses a code and non-code resource bidirectional mapping and consistency maintenance method, comprising the following steps:

[0009] A first storage space and a second storage space that are physically independent and logically associated are configured; wherein the first storage space is used to store source code and build configurations of a software project, and the second storage space is used to store task description data, constraint conditions and structured knowledge objects of the software project;

[0010] A globally unique association identifier is generated, and the association identifier is stored in the related task description of the second storage space in synchronization, and is associated to the corresponding code entity of the first storage space through the way of metadata marking;

[0011] An automatic collaboration engine is configured to monitor data change events related to the association identifier in the first storage space or the second storage space in real time;

[0012] When the data change event is monitored, an intelligent semantic processing module is triggered to extract context data in the two storage spaces based on the association identifier for cross analysis, and the following operations are performed: analyzing task constraint conditions in the second storage space, and dynamically generating corresponding verification logic or test cases in the first storage space; analyzing code change characteristics in the first storage space, and automatically generating or updating the structured knowledge objects in the second storage space.

[0013] In a preferred example, the analyzing task constraint conditions in the second storage space and dynamically generating corresponding verification logic or test cases in the first storage space further comprises:

[0014] From a piece of task description data in the second storage space, acceptance indicators in the form of natural language or pseudo code are identified and extracted;

[0015] The acceptance indicators are compiled into an automatic test script executable in the first storage space by using the intelligent semantic processing module;

[0016] The automatic test script is injected into the build process of the first storage space and executed; if the execution fails, a blocking signal is generated to intercept the code release process, and failure logs are fed back to the second storage space.

[0017] In a preferred embodiment, the parsing the code change feature in the first storage space, and automatically generating or updating the structured knowledge object in the second storage space further comprises:

[0018] Monitoring the code commit record of the first storage space;

[0019] When detecting a free code change not carrying the associated identifier, or detecting that the complexity of the code change exceeds a preset threshold: using the intelligent semantic processing module to analyze the syntax structure difference and runtime index influence of the code change; automatically generating a task draft containing a change intention abstract, a list of affected modules, and a recommended acceptance standard in the second storage space, and in response to a confirmation instruction for the task draft, converting the task draft into the structured knowledge object while completing the associated mapping.

[0020] In a preferred embodiment, the corresponding code entity associated with the first storage space through metadata tagging further comprises:

[0021] During the code editing or committing stage of the first storage space, using abstract syntax tree analysis technology to parse the source code structure;

[0022] Injecting the associated identifier as metadata into the comments, annotations, or extension attributes of the function, class, or module nodes related to the task to form a code fingerprint;

[0023] When the source code is renamed, moved, or logically refactored, tracking the code fingerprint through static analysis tools to maintain the persistent binding of the associated identifier to the corresponding code logic segment.

[0024] In a preferred embodiment, the method further comprises:

[0025] When creating or modifying task description data in the second storage space, using the intelligent semantic processing module to analyze the semantic intention of the task description and predict the target code files that may be involved in the first storage space;

[0026] Building a virtual sandbox to simulate the code changes that may be generated after the current task is implemented, and performing collision analysis with the code changes involved in other ongoing tasks in the first storage space;

[0027] Calculating the probability of potential logical conflicts and outputting a warning message in the second storage space before actual code writing.

[0028] In a preferred embodiment, the structured knowledge object is configured as a dynamic entity with a life cycle attribute, and the method further comprises:

[0029] record the frequency of reference, creation time and the activity of associated code of the structured knowledge object;

[0030] calculate the vitality index of the structured knowledge object according to a preset algorithm;

[0031] when the vitality index is lower than a preset threshold, automatically perform archiving or de-privileging operation;

[0032] when the vitality index is higher than a preset threshold and the content complexity increases, automatically propose, by the intelligent semantic processing module, to split the structured knowledge object into multiple sub-objects or extract a general pattern to an organizational level knowledge base.

[0033] In a preferred example, the intelligent semantic processing module adopts a multi-agent collaborative mechanism:

[0034] For the same associated identifier, multiple virtual agent roles with different functions are instantiated in the background of the system, including at least an agent responsible for architecture dependency analysis, an agent responsible for code implementation strategy, and an agent responsible for index measurement;

[0035] Multiple virtual agent roles independently evaluate the same data change event based on their respective preset prompt words and focus points, and generate comprehensive decision suggestions through a preset negotiation protocol.

[0036] In a preferred example, the method further introduces a third storage space as an intent verification layer:

[0037] Using the intelligent semantic processing module, only based on the task description data in the second storage space, the expected code skeleton is reversely generated and stored in the third storage space;

[0038] Semantically compare the actual submitted code in the first storage space with the expected code skeleton in the third storage space;

[0039] Calculate the deviation degree of intent and implementation, and write the deviation degree data back to the second storage space as a quality measurement index.

[0040] In a preferred example, the associated identifier contains a hierarchical coding structure, including at least project lineage code, intergenerational evolution code and mutation point code, for supporting cross-project task gene retrieval and success rate prediction.

[0041] The application also discloses a code and non-code resource bidirectional mapping and consistency maintenance system, comprising:

[0042] The storage module is configured to maintain a physically isolated first storage space and a second storage space;

[0043] an identifier management module configured to generate a globally unique correlation identifier and maintain a mapping relationship thereof in two storage spaces;

[0044] an automated collaboration engine configured to listen to data change events of either storage space;

[0045] an intelligent semantic processing module including a processor and a memory storing computer instructions, when the instructions are executed, for implementing the method described above.

[0046] In the embodiments of the present application, by configuring a task and code dual-warehouse architecture independent of each other, a cross-warehouse metadata mapping mechanism based on a globally unique correlation identifier is established, and an intelligent semantic processing module is introduced to respond to and cross-analyze bidirectional change events in real time, which can effectively realize the deep decoupling and dynamic synchronization of business requirements and technical implementation in the software development process. Specifically, this scheme breaks down the barriers that non-technical personnel cannot participate and knowledge assets cannot be deposited in the traditional single-warehouse mode, and uses an automated collaboration engine to build a bridge connecting "document constraints" and "code entities". On the one hand, by analyzing task constraints to dynamically generate verification logic, the mandatory guiding position of the requirement document to code development is established, preventing requirements from being disconnected from implementation. On the other hand, by automatically feeding back knowledge objects through code changes, the explicit and structured deposition of implicit development experience is realized, thereby significantly improving the traceability, closed-loop management efficiency, and organizational-level knowledge reuse capability of the software throughout its life cycle.

[0047] Further, by intelligently extracting acceptance indicators in natural language form from task descriptions and compiling them into executable automated test scripts in the construction process, static document constraints can be converted into dynamic "executable contracts", thereby instantly intercepting changes that do not meet business expectations during code construction, ensuring that the final deliverables strictly follow established quality and functionality standards, and fundamentally eliminating the phenomenon of "documents for reference only".

[0048] Further, by monitoring free code changes that do not carry identifiers or high-complexity changes, and using AI to analyze their syntax structure and runtime impact to generate task drafts and complete the mapping, a "reason from result" reverse closed-loop management mechanism can be established, effectively capturing process data in emergency fixes or temporary changes, filling in the management blind spot caused by the "code first, task later" in traditional processes, and ensuring the integrity of the audit link and the completeness of knowledge assets.

[0049] Further, by injecting the association identifier as metadata into the microstructure of code entities (such as functions, class annotations, or extension attributes) using Abstract Syntax Tree (AST) analysis techniques, and combining static analysis tools to track code fingerprints, the task ID can be persistently and accurately bound to the code logic fragments even in complex scenarios such as code renaming, file moving, or large-scale refactoring. This solves the fragility problem of traditional file path or commit record-based association, and realizes fine-grained code tracing.

[0050] Further, by predicting the code range involved based on semantic intent during task creation, and simulating code changes in a virtual sandbox to analyze collisions between multiple tasks, potential logic conflicts and integration risks can be predicted before the code is actually written. This gives developers a "god's eye view" of predictive ability, significantly reducing the probability of late-stage code merge conflicts and rework costs, and achieving "left shift" of development risk management.

[0051] Further, by giving structured knowledge objects life index, self-variation record, and other life cycle attributes, and automatically performing archiving, splitting, or pattern extraction operations based on activity and content complexity, a dynamic knowledge base with "metabolism" capability can be built to ensure that the accumulated experience cards remain timely and valuable. This solves the industry pain point of traditional knowledge bases becoming outdated due to lack of maintenance.

[0052] Further, by introducing a multi-agent collaboration mechanism, virtual agent roles focusing on architecture, implementation, and indicators are instantiated in the background, and negotiation protocols are established. This can upgrade the general assistance of a single model to a "virtual committee" decision-making of a simulated expert team. Through multi-dimensional confrontation and consensus mechanisms, the professionalism, comprehensiveness, and feasibility of AI-generated suggestions can be significantly improved.

[0053] Further, by introducing a third storage space as an intent verification layer, the expected code skeleton is generated based on the task description and compared with the actual submitted code for semantic comparison, which can quantify the "intent-implementation deviation" index, effectively identifying code implementations that pass testing but deviate from the original design intent, providing a new semantic consistency dimension for code quality assessment.

[0054] Further, by using a "task DNA" hierarchical coding structure containing project lineage, intergenerational evolution, and mutation point information, gene-level tracking of task evolution paths can be achieved, supporting cross-project, cross-cycle success pattern recognition and risk prediction, enabling organizations to extract rules from the "genetic information" of historical tasks to guide future project decisions and resource allocation.

[0055] Each technical feature disclosed in the summary of the application, in the detailed description of various embodiments and examples, and in the accompanying drawings, can be combined with each other feature to create various new technical solutions, unless such a combination is technically impossible. For example, in one example, features A+B+C are disclosed, in another example, features A+B+D+E are disclosed, features C and D are equivalent technical means that play the same role, and only one of them can be technically used, and feature E can be technically combined with feature C. Therefore, the technical solution of A+B+C+D should not be considered as having been disclosed, and the technical solution of A+B+C+E should be considered as having been disclosed. BRIEF DESCRIPTION OF DRAWINGS

[0056] Figure 1 is the overall architecture diagram of the code and non-code resource bidirectional mapping and consistency maintenance system according to an embodiment of the present application;

[0057] Figure 2 is a multi-agent collaborative process schematic diagram according to an embodiment of the present application;

[0058] Figure 3 is an ET card browser plug-in interface schematic diagram according to an embodiment of the present application. DETAILED DESCRIPTION

[0059] In the following description, numerous specific details are set forth to provide a thorough understanding of the present application. However, it will be apparent to those skilled in the art that the present application can be practiced without such specific details and that numerous variations and modifications from the described embodiments can be possible.

[0060] Embodiment One: Basic Implementation of Dual-bin Architecture and Identifier System

[0061] The embodiment provides a basic implementation scheme of a code and non-code resource bidirectional mapping and consistency maintenance method. In the embodiment, the first storage space and the second storage space are both configured based on a GitHub platform, and respectively carry different types of project resources. Specifically, the first storage space is configured as a development repository named EdgeTeam, and the directory structure includes a source code directory src / , a build product directory dist / , and an automated workflow configuration directory.github / workflows / . The second storage space is configured as a task repository named EdgeTeam-TaR, and the directory structure includes a task definition directory tasks / , a structured knowledge object storage directory cards / , and a context directory context / . The two repositories are completely independent at the physical level, are uniformly managed through an organization account of the GitHub, but are closely linked through an association identifier at the logical level. Figure 1 A typical system architecture is shown, which includes a double-warehouse (optionally triple-warehouse) structure and the connection relationship of each module.

[0062] The association identifier is designed in a hierarchical coding structure to support cross-project task gene retrieval and success rate prediction. In the embodiment, the coding format of the association identifier is defined as ET-{project pedigree code}-{generation evolution code}-{mutation point code}-{phenotype code}. Among them, the project pedigree code adopts Greek letter naming, such as Alpha, Beta, Gamma, etc., which is used to identify the project product line to which the task belongs; the generation evolution code adopts the format of G plus a number, such as G1, G2, G3, which represents the number of evolution layers that the task has undergone from the original requirement; the mutation point code adopts the format of M plus a version number, such as M1.0, M2.1, which records the major changes and sub-changes that occur in the task execution process; the phenotype code is used to describe the current state expression of the task, and the optional values include Draft, Active, Success, and Archived. Taking ET-Alpha-G3-M2.1-Success as an example, the identifier indicates that the third generation of derivative tasks belongs to the Alpha product line, and achieves a successful state after the first sub-change of the second major change.

[0063] To achieve the persistent binding of the associated identifier and the code entity, the embodiment uses the abstract syntax tree analysis technology to implant metadata markers at the code level. Specifically, during the code editing or submission stage, the system parses the source code through the TypeScriptCompiler API or Babel Parser to identify the function declaration nodes, class declaration nodes, and module export nodes. Subsequently, the system injects the associated identifier in the form of a JSDoc comment into the front position of the relevant node to form the code fingerprint. Taking JavaScript code as an example, the injected code form is as follows: the system adds a JSDoc block containing the @taskId tag before the function definition, and the content is ET-Alpha-G3-M2.1, thereby establishing the mapping relationship between the function and the corresponding task.

[0064] When the source code is renamed, moved, or logically refactored, the system tracks the migration path of the code fingerprint through static analysis tools. The embodiment uses a node matching algorithm based on semantic similarity. The algorithm first extracts the abstract syntax trees of the code before and after refactoring, then calculates the feature vectors of each node, including node type, parameter signature, function body hash value, and other dimensions, and finally finds the corresponding nodes before and after refactoring through cosine similarity matching. When the similarity exceeds the preset threshold (0.85 in this embodiment), the system automatically migrates the associated identifier of the original node to the new node, thereby maintaining the persistent binding relationship between the code fingerprint and the task.

[0065] The automated collaboration engine is configured based on the event-driven architecture of GitHub Actions. The engine deploys listeners in two repositories to monitor data change events related to the associated identifier in real time. In the first storage space, the event types monitored include code push events push, pull request events pull_request, and version release events release; in the second storage space, the event types monitored include task file change events, status tag change events, and card creation events. When any event is triggered, the engine passes the event payload to the intelligent semantic processing module through the Webhook mechanism for subsequent analysis.

[0066] Embodiment Two: Automatic Conversion of Constraints to Executable Tests

[0067] This embodiment is based on Embodiment One and describes in detail the technical implementation of automatically generating executable verification logic in the first storage space from the task constraints in the second storage space. This embodiment upgrades the metric card in the structured knowledge object to an executable contract test, enabling the document constraints to directly control the code construction process.

[0068] In the Markdown file of the second storage space, the acceptance indicators are embedded in a specific pseudo-code format. This embodiment defines a set of acceptance indicator description languages, with the basic syntax Expect: {indicator name} {comparison operator} {threshold value} {unit}. For example, the constraint on API response time is recorded in the metric card as Expect: API_Response_Time < 200 ms; the constraint on test coverage is recorded as Expect: Code_Coverage >= 80%; and the constraint on concurrent user support capability is recorded as Expect: Concurrent_Users >= 1000 users. These constraints are embedded in the Markdown document in the form of code blocks, facilitating the recognition and extraction of intelligent semantic processing modules.

[0069] The intelligent semantic processing module uses a large language model to compile and convert acceptance indicators into automated test scripts. In this embodiment, the system first extracts all constraints in the metric card that meet the Expect syntax through regular expression matching, and then assembles the extracted results together with the project's technical stack information (such as using Jest as the test framework and k6 as the performance testing tool) into prompts to call the DeepSeek inference model to generate corresponding test scripts. Taking the API response time constraint as an example, the k6 performance test script generated by the model contains the following logic: define a virtual user scenario, send an HTTP request to the target API endpoint, record the response time, and verify whether the response time is less than 200 milliseconds through the check function. The generated test script is stored in the test / contracts / directory of the first storage space, with the file name following the format {associated identifier}_contract.test.js.

[0070] The automated test script is injected into the build process of the first storage space through the GitHub Actions workflow. The workflow configuration file defines the contract test phase, which is executed after the unit test passes and before deployment. Specifically, the workflow first pulls the metric card file associated with the current branch identifier from the second storage space, then triggers the compilation script to generate the latest test cases, and finally executes the test and collects the results. If the test execution fails, i.e., there is any acceptance indicator that does not meet the standard, the workflow will generate a blocking signal to terminate the subsequent build and deployment steps, and at the same time add a failure tag to the corresponding pull request through the GitHub API.

[0071] The feedback mechanism of the failure log ensures the information loop between the two warehouses. When the contract test fails, the system automatically generates a failure report file under the corresponding task directory in the second storage space. The report content includes the failed acceptance indicator name, expected value, actual value, failure timestamp, and code commit hash value that triggered the failure. In addition, the system also updates the state field of the metric card, changing it from Monitoring to Violated, and displays it in red on the task board. Project managers and developers can directly view failure details through the ET card browser plug-in and quickly jump to the relevant code for repair.

[0072] Embodiment Three: Reverse Task Generation Based on Code Changes

[0073] This embodiment describes a technical solution for reverse generation of second storage space task descriptions from first storage space code changes, which is used to solve the problem of code creation before task creation in actual development scenarios. Traditional development processes assume that tasks are always created before code, but in practice there are many temporary fixes, technical pre-research, and urgent changes, etc. These code changes often lack corresponding task records, resulting in blind spots in project management.

[0074] The automated collaboration engine continuously monitors the code commit records of the first storage space and identifies orphaned code changes that do not carry associated identifiers. The identification algorithm is based on the following rules: First, parse the commit information of each code commit and check if it contains an associated identifier in the ET-xxx format; second, scan the code fingerprint annotations in the changed files to confirm the presence of the @taskId tag; finally, check if the naming of the branch to which the commit belongs conforms to the naming specification of feat / ET-xxx or fix / ET-xxx. When the above three checks are all negative results, the commit is marked as an orphaned code change.

[0075] In addition to the detection of missing identifiers, the system also evaluates whether the complexity of the code change exceeds the pre-set threshold. The complexity threshold defined in this embodiment includes three dimensions: the number of modified lines of code exceeds 50, the number of files involved exceeds 5, or the cyclomatic complexity increment exceeds 10. Complexity calculation is achieved through static analysis tools, and the system automatically performs analysis on the changed code after each commit, extracts the above indicators and compares them with the threshold. When any dimension exceeds the threshold, even if the commit carries an associated identifier, the system will mark it as a high-complexity change that needs to be reviewed. The above threshold can be adjusted according to the size and complexity of the project.

[0076] When a free code change or a high complexity change is detected, the intelligent semantic processing module is triggered to perform the reverse task generation process. The module first collects the complete context information of the change, including the file list of the change, the difference content, the submit author, the submission time, and the related runtime indicators (such as the build time change, the test coverage change). Then, the module calls a large language model to perform semantic analysis on the context and generates a task draft document. The draft content includes a change intention summary (inferred by the model according to the code difference and the submission information), a list of affected modules (derived from static dependency analysis), and recommended acceptance criteria (recommended by the model according to the change type).

[0077] The generated task draft is pushed to the drafts / directory of the second storage space, and a reminder notification is sent to the relevant developers through the browser plug-in ET card. The notification content is: a code change without a task record is detected, the change involves {number of files} files and {number of modified lines} lines of code, whether to accept as a formal task ET-XXX? Developers can preview the task draft through the plug-in interface and choose to accept, modify, or reject. If you choose to accept, the system automatically assigns a formal association identifier to the task, moves the draft to the formal task directory, and writes back to the code submission record in the first storage space, adding an association identifier note at the end of the submission information. If you choose to modify, the system opens the draft editing interface for manual adjustment. If you choose to reject, the system marks the change as a reviewed no-task change and no longer repeats the reminder.

[0078] Embodiment Four: Virtual Sandbox and Conflict Prediction Mechanism

[0079] This embodiment describes a virtual sandbox technical solution for predicting potential conflicts before code writing. In traditional development processes, code conflicts are usually discovered during the merge stage, at which point the cost of resolving conflicts is already high. This embodiment achieves front-end risk control in the development process by predicting conflicts during the task drafting stage.

[0080] When the user creates or modifies the task description data in the second storage space, the intelligent semantic processing module first performs semantic intention analysis on the task description. The analysis process uses natural language understanding technology to extract key entities and action intentions from the task description. For example, for a task described as optimizing the response speed of the user login module, reducing the verification time from the current 500ms to within 200ms, the module identifies the key entities including the user login module, the verification time, and the action intention for performance optimization. Then, the module matches the recognition results with the code library index in the first storage space to predict the target code files that may be involved, such as auth / login.js, services / validator.js, etc.

[0081] Based on the predicted target code file list, the system constructs a virtual merge sandbox for collision analysis. The sandbox environment is a temporary clone of the first storage space main branch, in which the system simulates the code changes that may be generated after the current task is implemented. The generation of simulated changes also relies on a large language model, which infers the possible modification range and modification method based on the task description and the existing code of the target file. The generated simulated changes are stored in the form of patch files, but will not be actually applied to any branch.

[0082] The collision analysis algorithm cross-compares the simulated changes of the current task with the code changes involved in other ongoing tasks in the first storage space. The algorithm calculates the conflict probability from the following dimensions: file overlap, i.e., the ratio of the intersection size to the union size of the target file sets involved in the two tasks; function overlap, i.e., the intersection proportion of the function sets that may be modified by the two tasks; logical dependency, i.e., the overlap degree of the indirect impact range determined through call chain analysis. The final conflict probability is calculated by the weighted average of the three dimensions, and the weights set in this embodiment are 0.4, 0.4, and 0.2, respectively.

[0083] The system adopts different response strategies according to different intervals of the conflict probability. When the conflict probability is less than 60%, the system only displays a low-risk prompt on the task details page and does not make mandatory intervention; when the conflict probability is between 60% and 80%, the system outputs orange warning information in the task description of the second storage space, with the content format being: Attention: Your task requirements may have a {probability value} logical conflict with the {associated identifier} task, and it is recommended to communicate with {responsible person name} before development; when the conflict probability exceeds 80%, the system outputs a red mandatory warning and sends a notification to the responsible persons of both parties through an instant messaging tool, requiring coordination before code writing. The warning information also contains a conflict file list and a conflict function list to facilitate developers to quickly locate potential problem areas.

[0084] Embodiment Five: Lifecycle Management of Structured Knowledge Objects

[0085] This embodiment describes a dynamic lifecycle management technical solution for structured knowledge objects. In this application, structured knowledge objects include three types of success cards, component cards, and metric cards, which are configured as dynamic entities with lifecycle attributes and can automatically evolve, split, or archive according to usage, thereby solving the industry pain points of long-term maintenance of knowledge bases.

[0086] The metadata of each structured knowledge object contains a life cycle tracking field. The system continuously records the following metrics: reference frequency, i.e., the number of times the object is referenced by other tasks, code comments, or documents in the past 90 days; creation time, i.e., the timestamp when the object is first generated; last modification time, i.e., the timestamp when the content of the object is last updated; and associated code activity, i.e., the submission frequency of the code files bound to the object through the association identifier in the past 30 days. These metrics are updated once a day by a background timing task.

[0087] The formula for calculating the vitality index is defined as V = α × R × T × A, where R represents the normalized reference frequency, T represents the timeliness decay factor, A represents the associated code activity factor, and α is the normalization coefficient. The timeliness decay factor uses an exponential decay model, and the calculation formula is T = e (-λ×d) where d represents the number of days since creation, and λ is the decay constant, which is set to 0.002 in this embodiment, corresponding to a vitality decay of about 50% in about one year. The associated code activity factor is calculated based on the submission frequency. When there is a submission of the associated code in the past 30 days, A takes the value of 1.0; when there is no submission but there is a submission in the past 90 days, A takes the value of 0.7; and when there is no submission for more than 90 days, A takes the value of 0.3. The final vitality index V is normalized to the interval of 0 to 1.

[0088] The system triggers different automated operations according to the threshold of the vitality index. When the vitality index is less than 0.1, the system performs archiving or de-weighting operations: moves the structured knowledge object from the active directory cards / to the archive directory archive / , reduces its weight ordering in the organization knowledge base search results, and adds the archived label and the archiving reason explanation in the object metadata. Before archiving, the system performs knowledge extraction on the object content through a large language model to generate a terminal abstract, recording the patterns and ideas in the object that still have migration value for future project reference.

[0089] When the vitality index is higher than 0.8 and the content complexity exceeds the preset threshold, the system triggers an automatic splitting proposal. The complexity threshold is calculated based on the number of characters, the number of chapters, and the number of embedded elements in the object. For high-activity complex objects that meet the conditions, the intelligent semantic processing module analyzes the content structure, identifies knowledge units that can be independently formed, and generates a splitting proposal. For example, a success card containing architecture design, implementation details, and performance optimization may be proposed to be split into three independent objects: architecture success card, implementation component card, and performance measurement card. The splitting proposal is presented to the object maintainer in the form of a pop-up window, and is executed after confirmation. In addition, when the system detects multiple similar structured knowledge objects (similarity is calculated by the cosine distance of semantic vectors, with a threshold of 0.85), it also proposes to merge them into one object, retaining the best practice content of each.

[0090] Example Six: Multi-agent Collaborative Decision-making Mechanism

[0091] This embodiment describes the technical implementation of the multi-agent collaborative mechanism in the intelligent semantic processing module. Unlike the traditional single large model solution, this embodiment splits the intelligent semantic processing capability into multiple virtual agent roles with different functions, and forms more comprehensive and professional decision-making suggestions through negotiation between agents.

[0092] For a task corresponding to the same association identifier, the system instantiates four virtual agent roles in the background. The first is the architect agent, whose function is to analyze the impact of the task on the overall architecture of the system, focusing on module dependency, interface compatibility, technical debt risk, etc. The second is the implementation agent, whose function is to evaluate the specific implementation strategy of the task, focusing on code complexity, implementation man-hour estimation, testability, etc. The third is the index officer agent, whose function is to monitor the measurement indicators related to the task, focusing on performance benchmarks, test coverage, acceptance standard achievement, etc. The fourth is the review officer agent, whose function is to extract the experience that can be deposited from the task, focusing on success factors, failure lessons, reusable patterns, etc.

[0093] Each agent role is configured with an independent prompt word template and output format specification. Taking the architect agent as an example, its prompt words include the following core instructions: As a system architect, please analyze the impact of this task on the existing architecture, focusing on the following aspects: whether to introduce new external dependencies, whether to change the responsibility boundaries of existing modules, whether there is a risk of circular dependency, whether it conforms to the current technology selection strategy. Please output the evaluation results in JSON format, including the impact_level (high / medium / low), risk_points (risk point list), and recommendations (suggestion list) three fields. The prompt word structure of other agents is similar, but the focus dimensions and output fields are different.

[0094] At key decision-making nodes (such as task initiation approval, code merge review, version release review), the system triggers the agent negotiation process. The process is divided into three stages (see Figure 2 ): independent evaluation stage, each agent generates evaluation results independently based on the current data change event and the context of the double warehouse; cross-examination stage, the evaluation results of each agent are summarized and then distributed to all agents, each agent can provide supplementary opinions or objections to the evaluation results of other agents; consensus formation stage, the system uses a weighted voting protocol to integrate the opinions of all agents to generate the final decision-making suggestion. In the weighted voting, the weight of each agent is dynamically adjusted according to the decision type, for example, in technical architecture-related decisions, the weight of the architect agent is 0.4, and in progress management-related decisions, the weight of the index officer agent is 0.4.

[0095] For cases where there is a clear disagreement between agents, the system employs a conflict resolution mechanism for handling. When the evaluation conclusions of any two agents are logically contradictory (such as the architect agent thinking the scheme is feasible while the implementation agent thinks it is not), the system extracts the point of disagreement and presents it to the human decision maker, along with the arguments of each agent. After the human decision maker makes a final judgment, the system writes the decision and its reasons into the decision log of the corresponding task as material for the subsequent learning and optimization of agent models. Through this human-machine collaborative way, the judgment ability of the agent can continuously evolve in the process of project advancement.

[0096] Embodiment Seven: Third Storage Space and Intent Verification Layer

[0097] This embodiment describes a technical solution that introduces a third storage space as an intent verification layer. This solution is used to solve the implicit problem of code meeting requirements but deviating from the original intention. By generating the expected code skeleton in reverse and comparing it with the actual code, the degree of deviation between intent and implementation is quantified.

[0098] The third storage space is configured as a shadow repository named EdgeTeam-Shadow, which has the same directory structure as the first storage space, but only stores code skeleton files generated by the intelligent semantic processing module in reverse, rather than actual executable source code. The creation and update of the shadow repository are fully automated and do not require direct operation by developers. Whenever the task description in the second storage space changes, the system triggers the synchronization update process of the shadow repository.

[0099] The process of generating the code skeleton in reverse is as follows: First, the intelligent semantic processing module reads the task description data from the second storage space, including functional requirements, acceptance criteria, technical constraints, etc. Second, the module combines the existing code structure of the first storage space (such as directory layout, naming conventions, dependency graph), and calls a large language model to generate the code skeleton that should theoretically be produced for this task. Finally, the generated code skeleton is stored in the corresponding location of the third storage space. The code skeleton is an abstract representation that contains the signature definition of classes and functions, key data structures, and pseudo-code descriptions of core algorithm processes, but does not contain specific implementation details.

[0100] When a code commit related to a task is generated in the first storage space, the system automatically performs the intent-implementation alignment analysis. The alignment process adopts a multi-level semantic matching algorithm: the structure layer alignment checks the correspondence between the actual code and the expected skeleton in terms of class, function, and module organization; the interface layer alignment verifies the consistency of function signature, parameter type, and return type; the logic layer alignment evaluates the similarity of algorithm flow through abstract syntax tree analysis. Each level outputs a matching score between 0 and 1, and the final deviation is calculated as 1 minus the weighted average of the matching scores of the three levels, with the weights set to 0.3, 0.3, and 0.4 in this embodiment.

[0101] The deviation data is written back to the second storage space as a quality metric indicator. The system adopts different processing strategies based on different intervals of deviation: when the deviation is less than 30%, it is considered as normal deviation and only recorded as statistical data; when the deviation is between 30% and 50%, the system adds a review suggestion label to the task's metric card, prompting the code reviewer to pay attention to the consistency between implementation and requirements; when the deviation exceeds 50%, the system triggers an early warning mechanism and sends a notification to the task owner, asking for confirmation of whether the actual implementation meets the original intent or whether the task description needs to be updated to reflect the design changes during implementation. In addition, the system also tracks the average deviation trend of each project over time, providing data support for continuous improvement of requirement writing quality.

[0102] Embodiment Eight: System Device Implementation

[0103] The present embodiment provides a code and non-code resource bidirectional mapping and consistency maintenance system, which has a structure as shown in Figure 1 The system includes four core components: a storage module, an identifier management module, an automated collaboration engine, and an intelligent semantic processing module.

[0104] The storage module is configured to maintain a physically isolated first storage space, a second storage space, and an optional third storage space. In this embodiment, the storage module is implemented based on the repository service of the GitHub platform, and the three storage spaces correspond to three independent Git repositories. The storage module also includes a distributed cache layer, which is deployed using Redis cluster to cache frequently accessed task metadata, code index information, and associated mapping tables, in order to improve the response performance of the system. The cache layer and the GitHub repository synchronize data through Webhook, and when the repository content changes, the related cache items are marked as invalid and reloaded on the next access.

[0105] The identity management module is configured to generate unique association identifiers and maintain their mapping relationship in each storage space. The module includes two sub-components, an identifier generator and a mapping registry. The identifier generator generates new association identifiers according to the hierarchical coding rules described in Embodiment I, and ensures the global uniqueness of the identifiers through a distributed lock mechanism during generation. The mapping registry is implemented based on a relational database, and stores the many-to-many mapping relationship between the association identifiers and the first storage space code entities, the second storage space task files, and the third storage space skeleton files. The registry also records the timestamp and operator information of each mapping change, supporting historical tracing of the mapping relationship.

[0106] The automated collaboration engine is configured to listen to data change events of any storage space and trigger corresponding processing flows. The engine adopts an event-driven architecture, and the core components include an event collector, an event router, and a task scheduler. The event collector subscribes to change notifications of each repository through the GitHub Webhook interface, and pushes the received event load to the message queue after standardization conversion. The event router consumes events from the message queue, and distributes them to the corresponding processing pipeline according to the event type and association identifier. The task scheduler manages the execution of each processing pipeline, supporting task priority setting, concurrency control, and failure retry mechanism. In this embodiment, the message queue uses Apache Kafka deployment, supporting a processing throughput of thousands of events per second.

[0107] The intelligent semantic processing module includes a processor and a memory storing computer instructions. The processor is deployed using a GPU server cluster, and in this embodiment, it is configured with 4 computing nodes equipped with advanced GPU graphics cards for running large language model inference tasks. The computer instructions stored in the memory include a model loading program, a prompt word template, a multi-agent negotiation protocol, and various semantic analysis algorithms. The module provides a RESTful API interface to the outside, supporting the calling of functions such as acceptance index compilation, reverse task generation, conflict prediction, vitality index calculation, agent negotiation, code skeleton generation, and deviation analysis. For computationally intensive tasks, the module uses an asynchronous processing mode, and the calling party obtains a task ID after submitting a request, and subsequently obtains the processing result through polling or callback.

[0108] The system further comprises a unified entry module, which is implemented as an ET card in the form of a browser plug-in. The ET card displays the version release state of the first storage space, the task progress board of the second storage space, the mapping relationship diagram of the associated identifiers, and the analysis result of the intelligent semantic processing module in a unified interface by calling the API interfaces of the above modules. The ET card supports deep integration with the GitHub page, and when a user browses a code file, the user can directly view the associated task description, and when the user browses a task file, the user can directly jump to the associated code location. In addition, the ET card also provides a shortcut operation entry, such as one-key task creation, one-key test case generation, one-key agent negotiation triggering, and the like, to reduce the operation threshold of users using the system. Figure 3 Fig. 2 shows an interface schematic diagram of an ET card browser plug-in.

[0109] Accordingly, the embodiments of the present application also provide a computer readable storage medium, which stores computer executable instructions. The computer executable instructions are executed by a processor to implement the method embodiments of the present application. The computer readable storage medium includes permanent and non-permanent, removable and non-removable media, which can be implemented by any method or technology to store information. The information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible by a computing device. According to the definition herein, the computer readable storage medium does not include transitory computer readable media, such as modulated data signals and carriers.

[0110] In addition, the embodiments of the present application also provide a computer program product, which includes computer executable instructions. The computer executable instructions are executed by a processor to implement the steps in the above method embodiments.

[0111] It is to be noted that, as used in this application, the terms "preferably," "further preferably," "more preferably," or the like are used to describe an embodiment than which the application is not necessarily limited. Moreover, the terms "include," "have," and the like, as used in this application, are used in the sense of "including but not limited to." Additionally, the terms "couple" and "coupled" should not be construed as being restricted to a direct connection between two components but should be understood to include indirect connections through one or more other components.

[0112] This specification includes various embodiments of the application described herein. Individual references to embodiments (e.g., "an embodiment" or "some embodiments" or "a preferred embodiment"); however, these embodiments are not mutually exclusive, unless indicated as such or otherwise apparent to one of skill in the art. It should be noted that the word "comprising" is used herein in the broadest sense to mean that other items can also be present in the application. It is also noted that the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise.

[0113] All documents mentioned in this specification are hereby incorporated by reference in their entirety in the disclosure of the application to the extent that it is necessary to do so to enable the disclosure to be made. In addition, it is to be understood that the phraseology or terminology employed herein, and not otherwise expressly stated, is intended to be interpreted in an inclusive sense and not in an exclusive sense. It is to be understood that any modification, equivalent replacement, improvement, etc. made within the spirit and principle of one or more embodiments of the present specification shall be included in the scope of protection of one or more embodiments of the present specification.

[0114] In some cases, the actions recited in the claims can be performed in a different order and still accomplish the desired results. Additionally, the process depicted in the figures does not necessarily require the particular order shown, or sequential order to achieve the desired results. In certain implementations, multitasking and parallel processing can be advantageous.

Claims

1. A code and non-code resource bidirectional mapping and consistency maintenance method, characterized in that, The method comprises the following steps: configuring a first storage space and a second storage space which are physically independent and logically associated; wherein the first storage space is used for storing source code and build configuration of a software project, and the second storage space is used for storing task description data, constraint conditions and structured knowledge objects of the software project; generating a globally unique association identifier, and synchronously storing the association identifier in the related task description of the second storage space, and associating the association identifier to the corresponding code entity of the first storage space by means of metadata marking; configuring an automated collaboration engine, and monitoring data change events related to the association identifier in the first storage space or the second storage space in real time; when the data change event is monitored, triggering an intelligent semantic processing module, extracting context data in the two storage spaces based on the association identifier for cross analysis, and performing the following operations: analyzing task constraint conditions in the second storage space, and dynamically generating corresponding verification logic or test cases in the first storage space; analyzing code change characteristics in the first storage space, and automatically generating or updating the structured knowledge objects in the second storage space; the operation of analyzing code change characteristics in the first storage space and automatically generating or updating the structured knowledge objects in the second storage space further comprises: monitoring code submission records of the first storage space; when detecting free code changes not carrying the association identifier, or detecting that the complexity of code changes exceeds a preset threshold: analyzing syntax structure differences and runtime index influences of the code changes by using the intelligent semantic processing module; automatically generating a task draft containing change intention abstract, affected module list and recommended acceptance standard in the second storage space, and in response to a confirmation instruction for the task draft, converting the task draft into the structured knowledge objects, and simultaneously completing association mapping.

2. The method of claim 1, wherein, the operation of analyzing task constraint conditions in the second storage space and dynamically generating corresponding verification logic or test cases in the first storage space further comprises: identifying and extracting acceptance indexes in natural language form or pseudo code form from a piece of task description data of the second storage space; compiling the acceptance indexes into an automated test script executable in the first storage space by using the intelligent semantic processing module; injecting the automated test script into the build process of the first storage space and executing; if the execution fails, generating a blocking signal to intercept the code release process, and feeding back failure logs to the second storage space.

3. The method of claim 1, wherein, the operation of associating to the corresponding code entity of the first storage space by means of metadata marking further comprises: analyzing source code structure by using abstract syntax tree analysis technology during code editing or submission stage of the first storage space; injecting the association identifier as metadata into the annotation, note or extension attribute of the function, class or module node related to the task, to form a code fingerprint; The association identifier is kept persistently bound to the corresponding code logic segment by tracking the code fingerprint via static analysis tools when the source code undergoes renaming, file moving or logic refactoring.

4. The method of claim 1, wherein, The method further comprises: When the task description data in the second storage space is created or modified, the semantic intention of the task description is analyzed by the intelligent semantic processing module, and the target code file that may be involved in the first storage space is predicted; A virtual sandbox is constructed to simulate the code changes that may be generated after the current task is implemented, and a collision analysis is performed with the code changes involved in other ongoing tasks in the first storage space; The potential logic conflict probability is calculated, and a warning information is output in the second storage space before the actual code is written.

5. The method of claim 1, wherein, The structured knowledge object is configured as a dynamic entity with a life cycle attribute, and the method further comprises: The reference frequency, creation time and activity of the associated code of the structured knowledge object are recorded; The vitality index of the structured knowledge object is calculated according to a preset algorithm; When the vitality index is lower than a preset threshold, an archiving or de-authorization operation is automatically performed; When the vitality index is higher than a preset threshold and the content complexity increases, the structured knowledge object is automatically proposed to be split into multiple sub-objects or the general pattern is extracted to the organizational level knowledge base by using the intelligent semantic processing module.

6. The method of claim 1, wherein, The intelligent semantic processing module adopts a multi-agent collaborative mechanism: For the same association identifier, multiple virtual agent roles with different functions are instantiated in the background of the system, including at least an agent responsible for architecture dependency analysis, an agent responsible for code implementation strategy, and an agent responsible for index measurement; The multiple virtual agent roles with different functions independently evaluate the same data change event based on their respective preset prompt words and focus points, and generate a comprehensive decision suggestion through a preset negotiation protocol.

7. The method of claim 1, wherein, The method further introduces a third storage space as an intention verification layer: Using the intelligent semantic processing module, only based on the task description data in the second storage space, the expected code skeleton is reversely generated and stored in the third storage space; The actual submitted code in the first storage space is compared with the expected code skeleton in the third storage space; The deviation degree of intention and implementation is calculated, and the deviation degree data is written back to the second storage space as a quality measurement index.

8. The method of claim 1, wherein, The association identifier contains a hierarchical coding structure, which at least includes a project lineage code, a generational evolution code and a mutation point code, for supporting cross-project task gene retrieval and success rate prediction.

9. A code and non-code resource bidirectional mapping and consistency maintenance system, characterized in that, It comprises: A storage module configured to maintain a physically isolated first storage space and a second storage space; An identifier management module configured to generate a unique association identifier and maintain its mapping relationship in the two storage spaces; An automated collaboration engine configured to listen to data change events in either storage space; An intelligent semantic processing module including a processor and a memory storing computer instructions, when the instructions are executed, for implementing the method of any one of claims 1 to 8.

Images