A Multi-Stage Software Development Method and System for Access Control Based on Declarative Protocols and Physical Evidence Storage
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-15
- Publication Date
- 2026-08-14
AI Technical Summary
[0005]针对现有技术存在的问题,本发明提供了基于声明式协议与物理存证的多阶段软件开发门禁方法及系统,将人工智能驱动的软件开发流程构建为可验证的状态机模型,通过声明式协议规范执行动作、物理存证执行轨迹,以及门禁审查协议履行状态及产物质量等操作,形成对人工智能执行单元行为的闭环约束,最终消除动作投机与过程不可追溯问题
Smart Images

Figure CN122570045A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of software engineering and artificial intelligence technology, and in particular to a multi-stage software development access control method and system based on declarative protocols and physical evidence. Background Technology
[0002] With the continuous improvement of large language model capabilities, leveraging AI execution units to drive automated software development has become a significant industry trend. Currently, typical automated development processes employ multi-stage lifecycle management, using gates at each stage to verify upstream deliverables and ensure they meet preset quality requirements before proceeding to downstream stages. However, existing regulatory methods struggle to effectively constrain the behavior of AI execution units. Specifically, when executing development tasks, AI execution units, in pursuit of efficiency or limited by the "black box" nature of the model itself, often tend to skip crucial intermediate steps such as requirements analysis and architecture design, directly generating code. This opportunistic behavior makes the development process difficult to trace, and the generated deliverables lack logical support. Furthermore, existing gate systems primarily rely on formal checks of the final deliverables (such as file existence and compilation success), failing to verify whether the AI execution units have actually executed the intermediate actions stipulated in the protocol.
[0003] Furthermore, the main control unit typically combines execution and supervision functions, resulting in highly centralized authority and a lack of effective constraints and checks and balances. On the other hand, development processes, verification rules, and action definitions are scattered across various scripts and configuration files, presenting a fragmented state that makes unified maintenance and dynamic adjustment difficult.
[0004] Therefore, how to suppress speculative behavior of artificial intelligence execution units to achieve process traceability and verifiable intermediate actions is a technical problem that urgently needs to be solved in this field. Summary of the Invention
[0005] To address the problems existing in the prior art, this invention provides a multi-stage software development access control method and system based on declarative protocols and physical evidence storage. It constructs the AI-driven software development process into a verifiable state machine model, and forms a closed-loop constraint on the behavior of AI execution units by specifying the execution actions through declarative protocols, the execution trajectory through physical evidence storage, and operations such as access control review of the performance status of the protocol and the quality of the output. This ultimately eliminates the problems of action speculation and process untraceability.
[0006] The technical solution of this invention is implemented as follows: A multi-stage software development access control method based on declarative protocols and physical evidence storage, employing an access control engine, includes the following steps: Step 1: Construct a protocol file; the protocol file is used to define multiple task stages of the software development process, and each task stage includes task actions, verification rules and task routing. The multiple task phases correspond to various stages in the software development lifecycle, such as requirements analysis, preliminary design, detailed design, database design, coding implementation, and software testing.
[0007] Task actions are atomic operations that must be performed in each task phase.
[0008] The task route declares the next task phase.
[0009] Step 2: Configure the main intelligent agent and several specialized intelligent agents; Step 3: The main intelligent agent schedules the specialized intelligent agents that match the current task stage according to the protocol file; Step 4: The specialized intelligent agent executes the task according to the task action and generates task output; after the execution is completed, the access control engine is called to perform task verification of the execution process. Step 5: The access control engine performs an authenticity review on the executed task action to assess the sufficiency of the task action; only when the review is passed will the process proceed to step 6; sufficiency of execution means whether the agent strictly follows each requirement, boundary condition, constraint and implicit semantic in the predetermined requirements when executing the task action, and completely executes all necessary steps without deliberately omitting, simplifying, bypassing or "taking shortcuts".
[0010] By verifying the authenticity of the executed actions, speculative behavior by AI execution units is curbed. If the verification fails, step 4 is re-executed. Step 6: The access control engine performs physical verification on one of the task stages; the physical verification includes: performing consistency verification on the task output according to the verification rules; proceeding to step 7 only when the verification passes; in this invention, consistency verification refers to verifying whether the data, code or files generated in software development conform to predefined rules, constraints or logical relationships, ensuring that they are correct, complete and without contradictions in the entire software system.
[0011] Step 7: Based on the task route, determine the next task stage as the current task stage; Step 8: Repeat steps 3 to 7 until all task stages are completed.
[0012] As a further optimization of the above solution, when entering any of the above task stages, the access control engine will lock the corresponding next task stage into an unexecutable state; Only after the physical verification passes will the access control engine unlock the next task stage to an executable state.
[0013] By using a lock and unlock mechanism for each task phase, the sequential dependencies between task phases are enforced, preventing non-compliant products from flowing downstream.
[0014] As a further optimization of the above scheme, each task stage is configured with a unique stage identifier; the task output records the stage identifier.
[0015] By configuring a unique stage identifier and recording that identifier in the product, the review process can uniquely trace and distinguish each task stage, avoiding confusion between products from different stages.
[0016] As a further optimization of the above scheme, the content of the task evidence storage includes: the stage identifier, the execution time of the task action, and physical evidence; The physical evidence includes file paths, terminal output summaries, and file modification traces.
[0017] By recording physical evidence, the actions of professional intelligent agents are made auditable and reproducible with objective evidence, preventing the output from deviating from the actual execution records.
[0018] As a further optimization of the above scheme, the authenticity review includes a task scale suitability test; The task size adaptability test includes statistically analyzing the file modification traces in the physical evidence and comparing the statistical results with the preset expected task size corresponding to the task stage. The review will fail if the statistical results do not match the expected task size.
[0019] By testing the adaptability of the task scale, we can verify whether the actual execution input of the professional intelligent agent is commensurate with the expected task scale.
[0020] As a further optimization of the above scheme, the authenticity review includes specific inquiry constraints; The specific query constraints include: sending a mandatory disclosure instruction to the professional intelligent agent, using the mandatory disclosure instruction to control the professional intelligent agent to generate the process and output of performing the task action, as well as the verifiable physical coordinates corresponding to each process and output; The review fails when the verifiable physical coordinates fail to locate information consistent with the information generated by the professional intelligent agent in the physical evidence.
[0021] By instructing the agent to disclose the actual task actions and their corresponding physical coordinates and comparing and verifying them, it is confirmed that the agent is not simulating or repeating abstract descriptions, but rather performing accurate operations and actions.
[0022] As a further optimization of the above scheme, the authenticity review includes non-authentic output detection; The detection of non-real output includes: extracting the semantic and structural features of the task product and matching them with non-real behavior patterns; the non-real behavior patterns include content emptiness, operation simulation, evasive responses, and repetitive placeholder outputs; The review fails when any of the described non-authentic behavior patterns are matched.
[0023] Specifically, empty content refers to text generated by the model that superficially conforms to grammatical and format requirements, but lacks specific factual information, logical progression, or substantive content. It often manifests as a large number of generic clichés, tautologies, or a reorganization of input information without any substantial incremental change, making it impossible for readers to obtain any meaningful answers or insights.
[0024] Operational simulation refers to a model that does not directly answer the user's question, but instead describes or simulates the internal operation process that it should perform. For example, it may claim that it is retrieving data from a database, analyzing user intent, or following some internal rules. The entire response remains a description of the action without providing an actual problem-solving result.
[0025] Avoidant responses manifest as the model avoiding a direct response to the core issue, instead employing methods such as shifting the topic, repeating parts of the question, acknowledging the problem without answering, or providing general safety statements or disclaimers unrelated to the question. In this way, a response is given on the surface, but the requested information or explanation is not actually provided.
[0026] Repetitive placeholder output refers to a model's response containing a large number of repeated words, phrases, punctuation marks, or meaningless characters, lacking information increment. This type of output is usually filler generated to meet length requirements or maintain output continuity, making the content appear redundant and mechanical, and lacking normal communicative value.
[0027] By extracting semantic and structural features of the product for non-realistic behavior pattern matching, it is possible to accurately identify whether the model is in a state of not truly performing understanding and reasoning, thereby effectively filtering low-quality, fake, or meaningless generated content, avoiding speculative output behavior of the agent, and suppressing speculative output behavior of the agent when it does not truly perform understanding and reasoning.
[0028] In practical implementation, a multi-channel filter combining rules and statistics is constructed: for "content voids," the word density and information entropy of the text are calculated and matched with a general cliché library; for "operation simulations," regular expressions or semantic role labeling are used to identify specific syntactic structures of "first person + metaverb" (such as "I will search"); for "avoidant responses," a natural language inference model is used to determine whether the answer contains the core information of the question, and a pre-built avoidance phrase library is used for detection; for "repetitive placeholder outputs," the redundancy is quantified by calculating the n-gram autocorrelation coefficient or the longest repeating substring within the text. These techniques are common practices in the current field of text quality assessment and content generation filtering, and are mature existing technologies. The specific operational processes are not the focus of this invention.
[0029] As a further optimization of the above scheme, the physical verification includes at least one of the following verification types: structural integrity verification, format compliance verification, and traceability completeness verification; The verification rules include: the conditions for entering / exiting the task stage, the automated verification program, and the necessary files contained in the task output, the necessary information elements and format constraints of the necessary files; The physical verification is performed according to the verification procedure.
[0030] As a further optimization of the above scheme, the structural integrity verification is to verify whether the necessary file exists in the task output, and whether the necessary information elements in the necessary file are not empty; if the necessary file does not exist or the necessary information elements are lacking, the verification fails; for example, it must contain "XX document" and "XX document" must have a specified directory.
[0031] The format compliance check is to verify whether the format of the task output conforms to the format constraints, such as file naming, document title, identifier naming, etc.; if it does not conform, the check fails. The traceability completeness verification involves checking whether a specified element in the upstream product has a corresponding overriding item in the downstream product; if an uncovered specified element exists, the verification fails. Upstream and downstream products are products from adjacent or cross-stages in the software development lifecycle. By forcibly verifying whether the traceability identifier in the upstream product is completely overridden by the downstream product, the traceability continuity between artifacts at each stage of the software development lifecycle is ensured, preventing upstream content from being omitted or lost in the downstream stage.
[0032] Furthermore, the task output includes executable instructions or code; the physical verification includes executable semantic verification; the executable semantic verification performs syntax checks and non-interactive confirmation on the instructions or code.
[0033] Non-interactive confirmation is an automated confirmation mechanism that requires no real-time human intervention or two-way dialogue. In this invention, it refers to a semantic verification process that does not require human intervention.
[0034] This invention also provides a system that applies the above-mentioned multi-stage software development access control method based on declarative protocols and physical evidence storage, including: The protocol management module is used to build or modify the protocol file; The intelligent agent management module is used to configure and manage the main intelligent agent and the specialized intelligent agents; The access control engine module is used to load the protocol file and control the main intelligent agent to start the software development process; and after the professional intelligent agent performs the task, it performs the task notarization, the authenticity review and the physical verification, and decides whether to proceed to the next task stage based on the verification results and task routing, until all task stages are completed. The file management module is used to manage the task outputs and the data generated by the task's notarization.
[0035] Compared with the prior art, the present invention achieves the following beneficial effects: (1) This invention describes the development behavior specifications in a unified manner through a declarative protocol, solidifies the execution trajectory of intermediate actions through physical evidence storage, and performs multiple verifications on the protocol performance status and product quality through access control review and physical verification, thereby forming a closed-loop constraint on the behavior of artificial intelligence execution units. Thus, in the development process, it realizes full-process closed-loop management with constrainable behavior, traceable process, and verifiable results, effectively suppressing speculative behavior and execution deviation of artificial intelligence execution units, improving the execution authenticity and output consistency of development tasks, ensuring that the final deliverables meet the preset specifications and quality standards, and effectively solving the problem that traditional methods are difficult to reliably constrain the behavior of intelligent agents.
[0036] (2) This invention transforms the vague “development specifications” that originally relied on human understanding into a clear “execution contract” that can be automatically executed and physically verified by a computer system, thereby achieving high-confidence process control and enabling the entire software development process to have traceable and auditable technical attributes, significantly improving the reliability and transparency of process execution.
[0037] (3) By setting up a main intelligent agent and professional intelligent agents, this invention realizes the isolation of responsibilities and the balance of power between different intelligent agents, avoiding the failure of self-correction ability due to the inherent cognitive bias, goal conflict or logical self-consistency trap of the same model or system, making it difficult to objectively discover errors, compliance risks or security vulnerabilities in the content generated by itself, ultimately resulting in the distortion of protocol execution and the loss of control over product quality.
[0038] (4) This invention has good scalability and flexibility. Developers only need to modify the declarative protocol file to define or adjust different development processes, task stages and verification rules, without making any modifications to the underlying access control engine code, achieving the technical effect of "process as configuration", which significantly reduces the system maintenance cost and customization threshold.
[0039] (5) The present invention can automatically verify whether the specified elements in the upstream product are fully covered in the downstream product through the physical verification mechanism, thereby ensuring the logical closed loop between the original requirements and the final test cases, effectively reducing the risk of element omission due to requirement changes or information transmission deviations, and is especially suitable for complex software development scenarios under large-scale team collaboration. Attached Figure Description
[0040] Figure 1 This is a flowchart illustrating the multi-stage software development access control method based on declarative protocols and physical evidence storage provided in this embodiment of the invention. Figure 2 This is a timing diagram of the multi-stage software development access control method based on declarative protocols and physical evidence provided in the embodiments of the present invention; Figure 3 This is a data structure table for the protocol list provided in the embodiments of the present invention. Detailed Implementation
[0041] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions in the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.
[0042] like Figures 1 to 2 As shown, this embodiment provides a multi-stage software development access control method based on declarative protocols and physical evidence storage, including the following steps: Step 1: Construct the protocol file; The protocol file is used to define multiple task phases of the software development process. Each task phase contains a unique phase identifier, task action, verification rules, and task route.
[0043] The multiple task phases correspond to various stages in the software development lifecycle, such as requirements analysis, preliminary design, detailed design, database design, coding implementation, and software testing.
[0044] Task actions are atomic operations that must be performed in each task phase.
[0045] The task route declares the next task phase.
[0046] The verification rules include: the conditions for entering / exiting the task phase, the automated verification procedure, and the necessary files contained in the task output, the necessary information elements of the necessary files, and the format constraints.
[0047] Taking the development process of a “XXXX Intelligent Assistant Platform” as an example, the complete lifecycle of the entire development task is defined as a directed acyclic process (that is, each stage can only move forward sequentially and will not loop back). The task stages include, in order: environment pre-check and authorization, logical requirement alignment, atomic specification refinement, system architecture modeling, planning and physical implementation, and functional acceptance testing.
[0048] The transition between each task phase is subject to mandatory physical auditing by the access control engine; if the upstream phase fails the audit, the downstream phase remains locked.
[0049] Before a task enters the control process, the access control engine first loads and parses the declarative protocol. The protocol describes the task stage nodes, the transition logic between stages, the atomic actions that must be performed in each stage, the compliance verification units for entering or exiting a stage, stage context dependencies, the stage artifact list, and the list of skills that must be forcibly loaded in that stage, all in a single structured file. Taking the logical requirement alignment stage as an example, the structured configuration of this stage in the protocol is as follows: Figure 3 As shown.
[0050] As a result, the development process, action dependencies, and physical verification logic are unified and converged into a single protocol, realizing "process as configuration"; when it is necessary to adjust the development topology or verification rules, only the structured protocol needs to be modified, without changing the access control engine's code itself.
[0051] Step 2: Configure the main intelligent agent and several specialized intelligent agents. In this embodiment, the main intelligent agent acts only as a process coordinator. Its system prompts are subject to hard constraints, prohibiting it from directly producing specifications, architecture designs, and core business code. The main intelligent agent must dispatch specialized intelligent agents with corresponding professional skills to complete specific tasks according to the subordinate execution unit types specified in each stage of the protocol, and only obtain their output paths.
[0052] Step 3: The main agent, according to the protocol file, schedules specialized agents that match the current task stage. Specifically, the main agent requests entry into a new task stage from the access control engine, which then parses the relevant information list for the new task stage from the protocol file.
[0053] Specifically, the task phases and requirements for different specialized intelligent agents are as follows: During the logical requirements alignment phase, the professional intelligent agent needs to use brainstorming methods to work with users to sort out functional requirements and produce a "Requirements Sorting Document", which includes: business objects, a list of functional features, actual user usage scenarios, a comparison table of coverage of each business object, and user confirmation records.
[0054] During the atomic specification refinement stage, the professional intelligent agent breaks down each use case into an independently verifiable acceptance item, and equips each acceptance item with a verification command that can be executed automatically without human intervention; at the same time, a "requirement and verification method comparison table" is established to ensure that each requirement can be traced and to produce a "requirement specification document".
[0055] During the system architecture modeling phase, the professional intelligent agent combines security review, systematic troubleshooting, and "test-first" methods to conduct security threat analysis and failure mode investigation of system interfaces and data flows (pre-identifying various possible error scenarios), and clarifies the test conventions for each requirement in the design, specifying "under what premise, what operation should be performed, and what result should be obtained", thus producing the "System Design Document".
[0056] During the planning and physical implementation phase, the specialized intelligent agent arranges the implementation plan according to the design document and completes the code writing, producing the "Implementation Plan Document" and the "Implementation Evidence Record".
[0057] During the functional acceptance testing phase, the professional intelligent agent follows the principle of "verification before completion" and executes the process of "first surveying the site, then actual operation, and finally preserving evidence" for each acceptance scenario in the "Requirements Specification Document", producing an "Acceptance Test Report".
[0058] Step 4: The specialized intelligent agent executes the task according to the task action and generates task products. The task products record stage identifiers. The task products are different for different task stages, and some task products contain executable instructions or code.
[0059] When entering any task stage, the access control engine will lock the corresponding next task stage into an unexecutable state.
[0060] After execution, the access control engine is invoked to perform task evidence storage on the execution process. In this embodiment, the content of task evidence storage includes: stage identifier, execution time of task action, and physical evidence. Physical evidence includes file path, terminal output summary, and file modification traces.
[0061] By configuring a unique stage identifier and recording this identifier in the deliverables, subsequent reviews can uniquely trace and distinguish each task stage, avoiding confusion between deliverables from different stages. Recording physical evidence provides auditable and reproducible objective evidence of the professional intelligent agent's actions, preventing output from deviating from actual execution records.
[0062] Step 5: The access control engine performs an authenticity review on the executed task actions to assess the adequacy of the task actions; only if the review passes will the process proceed to Step 6.
[0063] Specifically, the authenticity review includes task scale suitability testing, specific inquiry constraints, and detection of non-authentic output.
[0064] The task scale suitability test includes statistically analyzing file modification traces in physical evidence (such as the number of newly added or modified lines of code, file modification traces), and comparing the statistical results with the preset expected task scale corresponding to the task stage. If the statistical results do not match the expected task scale, the review fails. In this embodiment, if the physical change statistics show that the number of modified lines is significantly lower than expected, the access control engine will automatically refuse to allow this stage to enter the subsequent automated verification process and send a "suspected speculation" warning back to the main intelligent agent, requiring a new professional intelligent agent to complete the substantive work.
[0065] Specific inquiry constraints include: sending mandatory disclosure instructions to professional intelligent agents, using mandatory disclosure instructions to control the professional intelligent agents to generate the process and output of task actions, as well as the verifiable physical coordinates corresponding to each process and output; when the information consistent with the information generated by the professional intelligent agent cannot be located in the physical evidence based on the verifiable physical coordinates, the review will not pass.
[0066] The detection of non-authentic output includes: extracting the semantic and structural features of the task output and matching them with non-authentic behavior patterns; non-authentic behavior patterns include empty content, operational simulation, evasive responses, and repetitive placeholder outputs; when any non-authentic behavior pattern is matched, the review fails.
[0067] By verifying the authenticity of the executed actions, speculative behavior by AI execution units is curbed. If the verification fails, step 4 is re-executed. Step 6: According to the verification procedure, the access control engine performs physical verification for a task stage; physical verification includes: performing consistency verification on the task output according to the verification rules.
[0068] Specifically, physical verification includes at least one of the following verification types: structural integrity verification, format compliance verification, traceability completeness verification, and executable semantic verification.
[0069] In this embodiment, the structural integrity check is to check whether the necessary files exist in the task output, and whether the necessary information elements in the necessary files are not empty; if the necessary files do not exist or the necessary information elements are lacking, the check fails; for example, "XX document" must be included, and "XX document" must have a specified directory.
[0070] The format compliance check verifies whether the format of the task output conforms to format constraints, such as file naming, document title, identifier naming, etc.; if it does not conform, the check fails. Completeness verification involves checking whether a specified element in an upstream product has a corresponding covered item in a downstream product. If a specified element is not covered, the verification fails. Upstream and downstream products are products that are adjacent or span across stages in the software development lifecycle. For example, the access control engine extracts all requirement numbers from the "Requirement and Verification Method Comparison Table" in the "Requirement Specification Document" and automatically searches for them one by one in downstream products (such as acceptance test documents), requiring each requirement to be covered by the downstream (i.e., 100% coverage). If a requirement is not covered by the downstream, it is considered a failure and blocked.
[0071] By mandating verification to ensure that traceability identifiers in upstream products are fully covered by downstream products, the traceability continuity between artifacts at each stage of the software development lifecycle is ensured, preventing upstream content from being omitted or lost in downstream stages.
[0072] Physical verification includes: executable semantic verification, which performs syntax checks and non-interactive verification on instructions or code.
[0073] Non-interactive confirmation is an automated confirmation mechanism that requires no real-time human intervention or two-way dialogue. In this invention, it refers to a semantic verification process that does not require human intervention.
[0074] In addition, the access control engine also checks the signature information of the generator of the task product to confirm whether it was generated by the professional intelligent agent specified by the task protocol for this task stage; if it finds that the task product was directly produced by the main intelligent agent, it is determined to be a violation of the role isolation constraint and is blocked.
[0075] In this embodiment, the access control engine extracts the verification commands defined for each acceptance item from the "Requirements Specification Document". These commands are automatically executed without human intervention. The engine performs syntax checks and automatic verification on the commands in a controlled, isolated environment to ensure that the commands are error-free and can be executed automatically.
[0076] Only when the verification passes will the next task stage be unlocked to an executable state, proceeding to step 7. Step 7: Based on the task route, determine the next task stage as the current task stage; Step 8: Repeat steps 3 to 7 until all task stages are completed.
[0077] This embodiment also provides a system that applies the above-mentioned multi-stage software development access control method based on declarative protocols and physical evidence storage, including: The protocol management module is used to build or modify protocol files; users can customize, add, delete, or modify protocol files.
[0078] The agent management module is used to configure and manage the main agent and specialized agents; The access control engine module is used to load protocol files and control the main intelligent agent to start the software development process; and after the professional intelligent agent performs a task, it performs task authentication, authenticity review and physical verification, and decides whether to advance to the next task stage based on the verification results and task routing, until all task stages are completed. The file management module is used to manage task outputs and data generated from task documentation.
[0079] Based on the disclosure and teachings of the foregoing specification, those skilled in the art can make changes and modifications to the above embodiments. Therefore, the present invention is not limited to the specific embodiments disclosed and described above, and some modifications and changes to the present invention should also fall within the protection scope of the claims of the present invention. Furthermore, although some specific terms are used in this specification, these terms are only for convenience of explanation and do not constitute any limitation on the present invention.
Claims
1. A multi-stage software development access control method based on declarative protocols and physical evidence storage, employing an access control engine; characterized in that, Includes the following steps: Step 1: Construct a protocol file; the protocol file is used to define multiple task stages of the software development process, and each task stage includes task actions, verification rules and task routing. Step 2: Configure the main intelligent agent and several specialized intelligent agents; Step 3: The main intelligent agent schedules the specialized intelligent agents that match the current task stage according to the protocol file; Step 4: The specialized intelligent agent executes the task according to the task action and generates task output; After execution, the access control engine is invoked to perform task verification of the execution process; Step 5: The access control engine performs an authenticity review on the executed task actions to assess the adequacy of the task action execution. Proceed to step 6 only if the review is approved; Step 6: The access control engine performs physical verification on one of the task stages; the physical verification includes: performing consistency verification on the task output according to the verification rules; proceeding to step 7 only if the verification passes. Step 7: Based on the task route, determine the next task stage as the current task stage; Step 8: Repeat steps 3 to 7 until all task stages are completed.
2. The multi-stage software development access control method based on declarative protocols and physical evidence storage as described in claim 1, characterized in that, When entering any of the aforementioned task stages, the access control engine will lock the corresponding next task stage into an unexecutable state; Only after the physical verification passes will the access control engine unlock the next task stage to an executable state.
3. The multi-stage software development access control method based on declarative protocols and physical evidence storage as described in claim 1, characterized in that, Each task stage is configured with a unique stage identifier; the stage identifier is recorded in the task output.
4. The multi-stage software development access control method based on declarative protocols and physical evidence storage as described in claim 3, characterized in that, The content of the task evidence storage includes: the stage identifier, the execution time of the task action, and physical evidence; The physical evidence includes file paths, terminal output summaries, and file modification traces.
5. The multi-stage software development access control method based on declarative protocols and physical evidence storage according to claim 4, characterized in that, The authenticity review includes a task size suitability test; The task size adaptability test includes statistically analyzing the file modification traces in the physical evidence and comparing the statistical results with the preset expected task size corresponding to the task stage. The review will fail if the statistical results do not match the expected task size.
6. The multi-stage software development access control method based on declarative protocols and physical evidence storage according to claim 4, characterized in that, The authenticity review includes specific inquiry constraints; The specific query constraints include: sending a mandatory disclosure instruction to the professional intelligent agent, using the mandatory disclosure instruction to control the professional intelligent agent to generate the process and output of performing the task action, as well as the verifiable physical coordinates corresponding to each process and output; The review fails when the verifiable physical coordinates fail to locate information consistent with the information generated by the professional intelligent agent in the physical evidence.
7. The multi-stage software development access control method based on declarative protocols and physical evidence storage as described in claim 1, characterized in that, The authenticity review includes detection of non-authentic output; The detection of non-real output includes: extracting the semantic and structural features of the task product and matching them with non-real behavior patterns; the non-real behavior patterns include content emptiness, operation simulation, evasive responses, and repetitive placeholder outputs; The review fails when any of the described non-authentic behavior patterns are matched.
8. The multi-stage software development access control method based on declarative protocols and physical evidence storage according to claim 3, characterized in that, The physical verification includes at least one of the following verification types: structural integrity verification, format compliance verification, and traceability completeness verification; The verification rules include: the conditions for entering / exiting the task stage, the automated verification program, and the necessary files contained in the task output, the necessary information elements and format constraints of the necessary files; The physical verification is performed according to the verification procedure.
9. The multi-stage software development access control method based on declarative protocols and physical evidence storage as described in claim 8, characterized in that, The structural integrity verification is performed by verifying whether the necessary file exists in the task output and whether the necessary information elements in the necessary file are not empty; if the necessary file does not exist or the necessary information elements are missing, the verification fails. The format compliance check is to check whether the format of the task output conforms to the format constraints; if it does not conform, the check fails. The traceability completeness verification involves verifying whether a specified element in the upstream product has a corresponding covering item in the downstream product; if an uncovered specified element exists, the verification fails.
10. A system that applies a multi-stage software development access control method based on declarative protocols and physical evidence storage as described in any one of claims 1 to 9, characterized in that, include: The protocol management module is used to build or modify the protocol file; The intelligent agent management module is used to configure and manage the main intelligent agent and the specialized intelligent agents; The access control engine module is used to load the protocol file and control the main intelligent agent to start the software development process; Furthermore, after the professional intelligent agent performs the task, the task authentication, authenticity review, and physical verification are performed, and a decision is made on whether to proceed to the next task stage based on the verification results and task routing, until all task stages are completed. The file management module is used to manage the task outputs and the data generated by the task's notarization.