Two-way authoring method and system for structured DSL-based workflows

Abstract

The application discloses a kind of based on structured DSL's two-way creation method and system of workflow, and the application relates to the technical field of workflow, DSL parser is parsed to workflow DSL text, and standardized DSL text is generated;The step aliasing of standardized DSL text, node type and parameter information are mapped to the preset ability list by executing ability binding to standardized DSL text, semantic level checking is executed to standardized DSL text in the mapping process, and the accuracy of check record is improved.Structured workflow intent is converted to check record and standardized DSL text, and corresponding application handover metadata is generated in the preview stage of workflow intent, and the application processing with expiration protection is executed to target workflow according to application handover metadata;If application is completed, reverse serialization is executed to existing workflow, the structured description of current workflow is output, and editing is directly carried out in DSL layer, so that the accuracy of two-way creation event of workflow is improved.

Description

Technical Field

[0001] This invention relates to the technical field of workflow, and more particularly to a bidirectional authoring method and system based on a structured DSL workflow. Background Technology

[0002] With the rapid development of artificial intelligence technology, utilizing external AI agents to assist in workflow orchestration has become an important trend in improving the efficiency of business process automation. When acquiring target workflows and creating them, existing workflow systems often rely directly on free natural language or non-standardized underlying JSON / code snippets as input. They lack a standardized DSL text that is both machine-readable and human-reviewable as the core intermediate representation. Due to the lack of such a standardized text medium, the system struggles to strictly constrain and structure the workflow intent generated by the AI ​​agent. The system cannot accurately identify semantic errors such as missing capabilities, out-of-bounds parameters, or invalid attributes at the input end, causing errors to only occur at runtime. This severely reduces the accuracy of verification records, resulting in low accuracy of bidirectional workflow creation events. Summary of the Invention

[0003] The purpose of this invention is to overcome the shortcomings of the prior art. This invention provides a bidirectional creation method and system based on a structured DSL workflow.

[0004] This invention provides a bidirectional authoring method based on a structured DSL workflow, comprising: The target workflow is obtained, and the corresponding workflow DSL text is determined by combining it with the preset structured DSL. The workflow DSL text is then input into the DSL parser. The DSL parser parses the workflow DSL text and generates a normalized DSL text. Capability binding is performed on the normalized DSL text, mapping the step aliases, node types, and parameter information of the normalized DSL text to a preset capability list. During the mapping process, semantic-level verification is performed on the normalized DSL text, and the corresponding verification records are output. The verification records and normalized DSL text are converted into structured workflow intents, and corresponding application handover metadata is generated during the preview stage of the workflow intents. Based on the application handover metadata, application processing with expiration protection is performed on the target workflow. During application processing, if a change to the target workflow is detected, the current application processing is forcibly intercepted; if the application is completed, the existing workflow is reverse serialized, the structured description of the current workflow is output, and it is directly edited at the DSL layer to construct the bidirectional authoring event of the workflow.

[0005] This invention provides a bidirectional authoring system based on a structured DSL workflow, which is applied to the aforementioned bidirectional authoring method based on a structured DSL workflow. The bidirectional authoring system based on a structured DSL workflow includes: The text module is used to acquire the target workflow and determine the corresponding workflow DSL text by combining it with the preset structured DSL. The workflow DSL text is then input into the DSL parser. The DSL parser parses the workflow DSL text and generates a normalized DSL text. The verification module is used to bind the capabilities of the normalized DSL text, mapping the step aliases, node types and parameter information of the normalized DSL text to a preset capability list. During the mapping process, semantic-level verification is performed on the normalized DSL text and the corresponding verification record is output. The application module is used to convert verification records and normalized DSL text into structured workflow intents, generate corresponding application handover metadata during the preview stage of the workflow intents, and perform application processing with expiration protection on the target workflow based on the application handover metadata. The bidirectional authoring module is used to forcibly intercept the current application processing if a change is detected in the target workflow during application processing; if the application is completed, it performs reverse serialization on the existing workflow, outputs a structured description of the current workflow, and directly edits it at the DSL layer to construct the bidirectional authoring event of the workflow.

[0006] Compared with the prior art, the beneficial effects of the present invention are: (1) Obtain the target workflow and determine the corresponding workflow DSL text in combination with the preset structured DSL. Input the workflow DSL text into the DSL parser. The DSL parser parses the workflow DSL text and generates a normalized DSL text. Perform capability binding on the normalized DSL text and map the step aliases, node types and parameter information of the normalized DSL text to the preset capability list. In the mapping process, perform semantic-level verification on the normalized DSL text and output the corresponding verification record. The introduction of normalized DSL text fully considers the semantic-level verification of the normalized DSL text and improves the accuracy of the verification record.

[0007] (2) Convert the verification record and normalized DSL text into a structured workflow intent, and generate the corresponding application handover metadata in the preview stage of the workflow intent. Perform application processing with expiration protection on the target workflow based on the application handover metadata. If the target workflow has been changed during the application processing, the current application processing is forcibly intercepted. If the application is completed, reverse serialization is performed on the existing workflow to output the structured description of the current workflow and edit it directly in the DSL layer to construct the bidirectional creation event of the workflow. This further controls the application handover metadata, fully considers the structured description of the current workflow, and improves the accuracy of the bidirectional creation event of the workflow. Attached Figure Description

[0008] Figure 1 This is a flowchart illustrating the bidirectional authoring method based on a structured DSL workflow in an embodiment of the present invention. Figure 2 This is a flowchart illustrating step S11 of the bidirectional authoring method based on a structured DSL workflow in an embodiment of the present invention. Figure 3 This is a flowchart illustrating step S12 in the bidirectional authoring method based on a structured DSL workflow in an embodiment of the present invention. Figure 4 This is a flowchart illustrating step S13 in the bidirectional authoring method based on a structured DSL workflow in an embodiment of the present invention. Figure 5 This is a flowchart illustrating step S14 of the bidirectional authoring method based on a structured DSL workflow in an embodiment of the present invention. Figure 6 This is a schematic diagram of the structural composition of a bidirectional authoring system based on a structured DSL workflow in an embodiment of the present invention. Detailed Implementation

[0009] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0010] Please see Figures 1 to 6 A bidirectional authoring method based on structured DSL workflow is proposed and applied to workflow scenarios. The bidirectional authoring method based on structured DSL workflow includes: Step S11: Obtain the target workflow and determine the corresponding workflow DSL text by combining it with the preset structured DSL. Input the workflow DSL text into the DSL parser. The DSL parser parses the workflow DSL text and generates a normalized DSL text. Step S12: Perform capability binding on the normalized DSL text, mapping the step aliases, node types, and parameter information of the normalized DSL text to a preset capability list. During the mapping process, perform semantic-level verification on the normalized DSL text and output the corresponding verification record. Step S13: Convert the verification records and normalized DSL text into structured workflow intents, generate corresponding application handover metadata during the preview stage of the workflow intents, and perform application processing with expiration protection on the target workflow based on the application handover metadata. Step S14: During application processing, if a change is detected in the target workflow, the current application processing is forcibly intercepted; if the application is completed, the existing workflow is reverse serialized, the structured description of the current workflow is output, and it is directly edited in the DSL layer to construct the bidirectional authoring event of the workflow.

[0011] refer to Figure 2 In step S11, the specific steps are as follows: S111: Obtain the target workflow, which includes the target workflow identifier, snapshot version number, last update time token, and current capability list. Under the influence of context constraints, the external intelligent terminal determines the corresponding workflow DSL text based on the preset structured DSL. The workflow DSL text includes the workflow header, status, entry point, schedule, execution and data description, layout, branches, and optional rewrite sections, and inputs them into the DSL parser. S112: The DSL parser performs lexical and syntactic analysis on the workflow DSL text, parses it into a compact intermediate workflow representation that eliminates redundant comments and format differences, and reconstructs a standardized DSL text with a unified output format accordingly. S113: During this parsing phase, if a syntax error such as duplicate fields or missing segments is detected, the DSL parser immediately interrupts the generation process and outputs structured diagnostic information of the location metadata, thereby achieving syntax-level interception at the input end.

[0012] In step S111, the specific steps are as follows: At this point, the system receives the operation request for the target workflow and extracts the complete context information of the target workflow from persistent storage or the runtime environment. This context information is structured to include at least: the target workflow identifier, used to globally and uniquely index the current operation entity; the snapshot version number, used to define the structural baseline of the current workflow; the last update time token, which serves as the basic credential for optimistic concurrency control to support subsequent expiration protection mechanisms; and the current capability list, which encompasses the capability catalog and parameter constraints of all available nodes in the current workflow runtime environment. In addition, the context information may optionally include the current workflow snapshot to provide a complete anchoring benchmark for subsequent rewriting of existing processes.

[0013] The system injects the acquired contextual information, especially the current capability list and the target workflow identifier, as contextual constraints into the external intelligent terminal. Under the influence of the above contextual constraints, the external intelligent terminal abandons the fuzzy inference of free natural language and strictly generates the corresponding workflow DSL text according to the preset structured DSL syntax specification. This process ensures that the output of the intelligent terminal is strictly limited within the capability list and syntax boundaries, eliminating capability overreach and structural ambiguity from the source.

[0014] At this point, the structured DSL adopts a human-readable and machine-parsable text format. Its overall syntax rules are built based on a combination of key-value pairs and hierarchical indentation, and it does not depend on a specific programming language environment. Specifically, a complete workflow DSL text is organized into several mandatory or optional semantic paragraphs. Each paragraph begins with a specific domain keyword as its identifier, followed by a pair of curly braces, and declares the specific configuration in the form of "attribute name: attribute value".

[0015] The entire DSL text does not contain natural language annotations or unstructured descriptions. All information is presented in the form of key-value pairs or predefined keywords, which allows the parser to perform lexical analysis through a finite state machine and syntactic derivation through a context-free grammar, completing the parsing without relying on external semantic libraries or artificial intelligence models.

[0016] The workflow DSL text generated by the external intelligent terminal is constructed as a compact, structured paragraph containing the complete semantics of the workflow. Specifically, the text must include: a workflow header, used to declare basic metadata; states, defining the initial and final state constraints of the process instance; entry points, indicating the conditions and ports that trigger the process; a plan diagram, describing the directed acyclic topology relationships between nodes; execution and data descriptions, mapping the runtime logic and input / output flows of nodes; a layout description, carrying the spatial coordinate information for visualization rendering; and branch definitions, the topology structure of constraint routing. Additionally, the text may include optional rewrite sections, which, in existing workflow rewrite scenarios, are used to declare the anchor points and replacement ranges for local rewrites.

[0017] The system inputs the workflow DSL text, which contains complete semantic paragraphs and contextual constraint information, as a pure character stream into the DSL parser to trigger subsequent lexical and syntactic parsing processes, thus completing the transformation from natural creative intent to machine-processable intermediate representation.

[0018] In step S112, the specific steps are as follows: At this point, after the DSL parser receives the DSL text character stream from the workflow, it first triggers the lexical analysis stage. In this stage, based on the preset DSL lexical rules, the input character stream is converted into a token sequence with definite lexical attributes through a finite state machine. During this process, the parser simultaneously performs a redundancy stripping operation, selectively filtering out "comment information without semantic support, such as explanatory annotations" and non-standard "format differences, such as irregular indentation, redundant blank lines, and non-standard whitespace characters." This ensures that the input information is reduced from unstructured or semi-structured free text to a token stream composed purely of core lexical units, thereby eliminating the interference of differences in expression habits when the external intelligent terminal generates text on the subsequent grammatical structure.

[0019] After acquiring the token stream, the parser enters the syntactic analysis phase. In this phase, based on the context-free grammar of the DSL or its extended production rules, the parser performs top-down or bottom-up reduction and derivation on the token stream to verify the legality of its syntactic structure. At the same time, the parser maps the token stream into a compact workflow intermediate representation. This intermediate representation is preferably a stable directed abstract syntax tree or attribute graph structure. This structure logically and strictly preserves the core semantic nodes such as workflow head, state, entry, plan graph, branch definition, and rewrite segment, as well as their hierarchical subordination and topological connection relationships. It eliminates the linear arrangement features in the original text, forming a memory computing model that is easy for machines to traverse, query, and modify.

[0020] After successfully constructing a compact workflow intermediate representation, the parser triggers a reverse serialization mechanism to perform format reconstruction based on the intermediate representation. The system traverses the semantic nodes and topological edges of the intermediate representation, strictly following the preset standard DSL typesetting specifications, such as unified indentation levels, standardized line break rules, and unified parenthesis and delimiter styles, to regenerate a standardized DSL text with a unified format. This standardized text is semantically equivalent to the original input text, but eliminates any personalized writing style in its presentation, providing a stable and predictable text baseline for subsequent capability binding verification, multi-round editing, and manual review.

[0021] In step S113, the specific steps are as follows: At this point, as the DSL parser transforms the workflow DSL text into a compact intermediate workflow representation, the parser simultaneously triggers a syntax structure validity inspection mechanism. This mechanism performs a deep traversal of the constructed abstract syntax tree or graph model and executes four types of core checks against preset syntax constraint rules: the first is field duplication detection, which identifies whether the same step alias or parameter key name is declared within the same level or scope; the second is segment missing detection, which verifies whether the workflow DSL text is missing essential semantic segments such as workflow header, entry point, and schedule diagram.

[0022] When the parser detects any unreasonable syntax error during the above inspection process, it immediately triggers an interruption exception. At this time, the parser abandons all downstream operations that are currently being executed, such as subsequent semantic analysis, intermediate representation improvement, and normalized DSL text reconstruction, and blocks the current workflow DSL text from entering the subsequent capability binding and preview application stage. This immediate interruption mechanism aims to forcibly intercept illegal input at the front end of the parsing pipeline to prevent structurally flawed intermediate representations from flowing downstream and causing unpredictable logical failures or system state pollution.

[0023] While interrupting the generation process, the parser locates the syntax node that triggered the error and extracts the location metadata of that node in the original workflow DSL text. This location metadata includes at least the starting line number, column number, ending line number, and column number of the error, or it contains the identification information of the semantic paragraph where the error is located. The parser encapsulates the error type, error description, and the above location metadata in a structured manner, generates structured diagnostic information, and outputs it externally. This structured diagnostic information provides precise error anchors for external intelligent terminals or human reviewers, thereby achieving fine-grained and traceable syntax-level interception at the input end.

[0024] refer to Figure 3 In step S12, the specific steps are as follows: S121: Perform deep capability binding on the normalized DSL text. By traversing the step aliases, node types and parameter information of each node, map them to the capability directory and description information in the preset capability list to complete the semantic association of runtime instances. S122: Semantic-level verification is performed synchronously during the mapping process. If a semantic-level error occurs in the capability list, the subsequent processing flow is directly blocked and a semantic-level blocking record is generated. S123: If the mapping pass information is received, the metadata, parameter constraints and version dependency information in the capability catalog are written back to the normalized DSL text, thereby generating a fully bound verification record, so that the workflow DSL text has complete runtime semantic expression and self-verification capability. In step S121, the specific steps are as follows: At this point, after obtaining the parsed and generated normalized DSL text, the system triggers a deep traversal mechanism. This traversal mechanism visits each workflow node declared in the plan diagram and execution description one by one, following the topological logic of the abstract syntax tree or compact intermediate representation of the normalized DSL text. During the traversal, the system accurately extracts the core elements of the current node. These core elements include at least the step alias used for logical addressing, the node type used to define the execution logic, and parameter information used to configure runtime behavior, including parameter key names and parameter values, thereby providing a complete data source to be bound for subsequent mapping and comparison.

[0025] The system extracts the core elements of the nodes and initiates a mapping and matching operation with a pre-defined capability list. This capability list predefines the capability directory and description information of all available capabilities in the current workflow environment. The capability directory specifies the legal set and hierarchical affiliation of node types, while the description information specifies the parameter key names, parameter value types, and value range constraints supported under each type of node. The system compares the node type with the capability directory to establish the node's classification and affiliation in the capability system. It anchors the step alias with the unique identifier in the capability directory and matches the parameter information with the description information under the corresponding type item by item. Thus, at the logical level, the declarative nodes in the DSL text are transformed into semantically related entities with clear runtime execution directions.

[0026] After a successful mapping match, the system generates a semantic association annotation for the runtime instance of the current node. This annotation process dynamically attaches the corresponding underlying execution component identifier, port constraint definition, and parameter default value rules from the capability list to the intermediate representation node of the standardized DSL text. Through this stage, the workflow node, which originally only had text declaration attributes, is given a precise backend execution semantic and scheduling boundary, so that the workflow intent is upgraded from a static structured text description to a runtime instance model that can be directly recognized and scheduled by the workflow engine, thus completing the closed loop of deep capability binding.

[0027] In step S122, the specific steps are as follows: At this point, while mapping the step aliases, node types, and parameter information of each node in the standardized DSL text to the preset capability list, the system simultaneously triggers a semantic-level verification mechanism. This mechanism uses the capability directory and description information as the gold standard to perform a deep constraint comparison on the mapped objects, focusing on examining four types of semantic-level errors: First, capability missing, i.e., the node type cannot find a matching item in the capability directory of the current capability list; second, capability unavailable, i.e., although the node type exists, its current state is marked as disabled or beyond the permitted range; third, attribute unsupported, i.e., the parameter key name declared by the node is not defined in the description information of the corresponding capability; fourth, invalid attribute value, i.e. although the parameter key name is valid, the parameter value passed in violates the data type, enumeration range, or logical constraints specified in the description information. The above comparison and mapping operations are executed atomically within the same traversal cycle to ensure the real-time nature of semantic verification.

[0028] When the system identifies any semantic-level error during the constraint comparison process, it immediately interrupts the current traversal mapping operation and triggers the process blocking mechanism. This mechanism directly cuts off the transmission channel of the current workflow DSL text downstream to the "conversion stage: such as the generation of structured workflow intents or patch preview models" at the logical level, freezing any preview and application operations for the target workflow. This forced blocking design aims to intercept semantic defects that violate runtime capability constraints before the business logic takes effect, preventing unexecutable or unsafe workflow intents from entering the preview and application pipeline, thereby eliminating the risk of crashes caused by the underlying runtime due to lack of capabilities or out-of-bounds parameters at the system architecture level.

[0029] While forcibly blocking subsequent processing, the system extracts the context information of the node that triggered the error, generates a structured semantic-level blocking record, and outputs it externally. This blocking record includes at least: the alias of the step where the error occurred, used to accurately locate the defective node; the error type identifier, such as missing capability or invalid attribute value, used to classify the error category; the expected constraint description, extracted from the legal description information of the capability in the capability list; and the actual conflict content, recording the specific assignment in the current DSL text that caused the verification failure. This structured blocking record provides clear self-reflection basis for external intelligent terminals or human reviewers, supporting them to perform precise targeted correction at the DSL layer, thereby completing the closed loop of semantic-level interception and error correction.

[0030] In step S123, the specific steps are as follows: At this point, the system monitors the mapping status in real time during the deep capability binding and semantic-level verification process. When all nodes in the normalized DSL text have been traversed and no semantic-level error blocking has been triggered, the system generates and outputs mapping pass information. Upon receiving the mapping pass information, the system immediately triggers the metadata reverse writing mechanism, marking the transformation of the workflow text from the static declaration stage to the runtime complete declaration stage, providing a semantically complete data foundation for subsequent structured transformation.

[0031] Based on the established mapping relationship, the system makes the implicit constraint information in the preset capability list explicit and writes it back to the corresponding node attributes of the normalized DSL text. This back-writing operation specifically includes three dimensions: First, metadata back-writing, which writes the underlying execution component identifier, input / output port specifications, and runtime resource quota corresponding to the node type in the capability catalog into the DSL node; second, parameter constraint back-writing, which appends the default values, data type limits, enumeration ranges, and mandatory validation rules defined in the capability description information to the node's parameter declaration; and third, version dependency back-writing, which injects the runtime environment version, minimum compatible version of the component library, and other dependencies that the current node depends on into the workflow header or node metadata. Through the above back-writing, the normalized DSL text is enhanced into a full DSL text carrying the complete runtime context.

[0032] After the reverse write operation is completed, the system generates a fully bound verification record based on the enhanced full DSL text. This verification record not only contains a summary of the workflow's topology structure, but also embeds the reverse-written parameter constraint rules and version dependency baseline as verification credentials into the text. Thus, the workflow DSL text itself carries a complete set of rules for determining the legality of subsequent modifications, giving it runtime semantic expression and self-verification capabilities. In subsequent bidirectional round-trip editing, any incremental modification to this DSL text can be directly self-verified locally based on its embedded constraint rules, without the need for frequent requests to external capability lists, significantly improving the real-time performance and security of bidirectional creation.

[0033] refer to Figure 4 In step S13, the specific steps are as follows: S131: Obtain the verification record and convert it in combination with the normalized DSL text. In the conversion process, the underlying syntactic features of the normalized DSL text are stripped away, and the structured runtime intent is extracted. This runtime intent can directly drive the workflow engine to execute. S132: Real-time monitoring of the preview stage of runtime intent. Generate a preview view based on the workflow intent, which includes a processing summary, compact DSL text, diagnostic information, and application handover metadata. At this time, follow the read-only principle and never directly modify the target workflow. S133: When a rewrite segment is detected in the workflow DSL text, the current authoring mode is mapped to an existing workflow rewrite. Based on the anchoring identifier in the rewrite segment, a local subgraph of the existing workflow is extracted, and an anchored local rewrite preview is performed to visually demonstrate the impact of the rewrite. After manual confirmation, application processing with expiration protection is performed based on the last update time token carried in the application handover metadata.

[0034] In step S131, the specific steps are as follows: At this point, the system obtains the full binding verification record generated by the previous steps. This verification record serves as a credential for the semantic completeness of the normalized DSL text. After receiving the verification record, the system extracts the mapping pass status and reverse write constraint information encapsulated within it to confirm that the current normalized DSL text has a complete runtime semantic expression. This provides a safe and semantically closed input source for subsequent structured downconversion, preventing unbound or semantically incomplete text from entering the intent extraction pipeline.

[0035] During the conversion process, the system performs an abstraction and dimensionality reduction operation on the normalized DSL text. This operation selectively removes the underlying syntactic features in the normalized DSL text that exist only to satisfy human readability or the generation habits of external intelligent terminals, including but not limited to: redundant text delimiters, hierarchical indentation marks, annotation fragments, DSL domain keyword declarations, and text connectors between node declarations. By removing the above-mentioned syntactic sugar and format packaging that only serve the text representation, the system degrades the declarative structure in plain text form into a decontextualized graph topology that retains only the core logical flow and data mapping relationship.

[0036] While stripping away the underlying syntactic features, the system extracts structured runtime intents from the dimensionality-reduced structure based on the metadata and parameter constraints written backwards in the verification records. This extraction process maps node types to execution component identifiers that the engine can recognize, transforms parameter information into input-output data contracts that meet the requirements of strong runtime typing, and transforms topological connections into directed edge-driven sequences that the engine scheduler can parse. The resulting runtime intents, as an intermediate data structure decoupled from specific DSL grammars, can be directly loaded and driven to execute by the workflow engine.

[0037] In step S132, the specific steps are as follows: At this point, after the system passes the structured runtime intent to the preview pipeline, it immediately starts a real-time monitoring mechanism. This mechanism builds a sandbox isolation space independent of the production environment during the preview phase, and monitors the entire lifecycle of the runtime intent parsing and rendering process. The system intercepts any instruction that attempts to cross the preview boundary and directly initiate a write request to the target workflow in persistent storage, ensuring the absolute read-only nature of the intent preview process, thereby preventing irreversible pollution of existing workflows caused by misoperation or unauthorized access at both physical and logical levels.

[0038] Based on the current workflow intent to be previewed, the system performs multi-dimensional data extraction and reorganization to generate a structured preview view. This view consists of four core elements: First, a processing summary, where the system extracts node topology changes, capability call counts, and key parameter adjustments from the runtime intent using natural language or structured methods to form a macro overview for quick human review; second, a compact DSL text, where the system reverse-serializes the runtime intent stripped of its underlying syntactic features into a simplified DSL form, removing redundant whitespace and comments, for low-context-burden logical comparison by external intelligent terminals; third, diagnostic information, where the system summarizes the semantic pass status in the preceding verification records and the simulated operation warnings in the preview stage to form a complete health assessment report; and fourth, application handover metadata, where the system encapsulates the version baseline, snapshot identifier, and intent hash value of the current workflow intent into an immutable handover credential, providing a security anchor for subsequent application processing.

[0039] Throughout the entire process of generating and outputting the preview view, the system strictly adheres to the read-only principle. Through database transaction isolation mechanisms and memory snapshot technology, the system ensures that the generation operation of the preview view is executed only in an independent copy or memory mapping. The original data structure, node connections, and parameter configurations of the target workflow in the storage medium remain absolutely static and untouched. This read-only protection mechanism strongly isolates "intent review" and "entity modification" in terms of time and space, ensuring that any intelligent generation intent that has not been finally confirmed by humans cannot have a substantial impact on the production environment, thus fundamentally guaranteeing the security of the workflow system.

[0040] In step S133, the specific steps are as follows: At this point, the system performs real-time detection of the structural paragraphs of the workflow DSL text in the preview pipeline. When it detects that the text contains optional rewrite paragraph declarations, the system immediately triggers the mode switching mechanism. The system adaptively maps the current creation mode from the full creation mode to the existing workflow rewrite mode. In this mode, the system no longer treats the DSL text as an independent and complete creation process, but parses it into an incremental modification instruction set for the existing runtime workflow, thereby establishing a correlation mapping between local modifications and the global existing context.

[0041] After the system enters the existing workflow rewriting mode, it deeply analyzes the anchor identifiers declared in the rewriting segment. These anchor identifiers are used to uniquely specify the target logical node or connection range to be rewritten in the existing workflow. Based on these anchor identifiers, the system selectively extracts a local subgraph from the persistently stored complete snapshot of the existing workflow, with the anchor node as the core and including its direct upstream and downstream data dependencies and control dependencies. This extraction operation converges the huge global topology into a finite local range, providing the scope boundary for subsequent precise rewriting.

[0042] The system will overwrite or insert the new logical structure declared in the rewrite section into the extracted local subgraph, replacing the original logic pointed to by the anchoring identifier, and perform an anchored local rewrite preview. During this process, the system uses a topology comparison algorithm to calculate the port type changes, data flow redirection, and upstream and downstream dependency path changes caused by the rewrite operation, and converts the above change trajectory into highlighted marks or difference connection lines, which are then visualized in the preview view. This allows for an intuitive and accurate display of the impact of the rewrite operation on the existing workflow, providing a clear decision-making basis for manual review.

[0043] Once the partial rewrite preview has been manually reviewed and confirmed to be correct, the system receives the manual confirmation instruction and executes entity application processing based on the application handover metadata generated during the preview phase. During this process, the system extracts the last update time token carried in the application handover metadata and performs an optimistic concurrent comparison with the actual last update timestamp of the target workflow in the current persistent storage. If the two are completely consistent, it is determined that the target workflow has not been modified by a third party during the preview period, and the system then securely distributes the rewrite intent to the application. If the determination is inconsistent, the expiration protection mechanism is triggered, the current application processing is forcibly intercepted, the target expiration result is returned, and a re-initiation of the check and preview is required, thereby completely eliminating data overwriting and logical conflicts caused by concurrent rewrites from multiple terminals.

[0044] The core of the expiration protection mechanism is application pre-verification and transaction-level rollback based on an optimistic concurrency control strategy. Specifically, when the system generates application handover metadata during the preview phase, it extracts two inseparable fields from the persistent storage records of the target workflow: one is an auto-incrementing or timestamp-based snapshot version number automatically maintained by the database, which increments automatically whenever any attribute of the workflow changes; the other is a last update time token, which has a timestamp accurate to the millisecond level and is automatically written by the database each time an update operation is triggered.

[0045] These two fields are encapsulated into the application handover metadata during the preview phase, serving as credentials for subsequent application processing. Once the user confirms the preview and triggers application processing, before performing any write operations, the system first initiates a conditional update statement to the database using the target workflow identifier as the primary key. The update condition of this statement mandates that the current snapshot version number in the database must be equal to the version number recorded during the preview phase, and the last update time token must be exactly the same.

[0046] If the database returns one affected row, it means the condition is met, the system is granted update permission, and then begins to execute actual write operations such as node insertion, connection adjustment, or parameter modification. All operations are completed within the same database transaction, and the version number is checked again before the transaction is committed to ensure it has not been changed by other transactions.

[0047] If the conditional update statement returns zero affected rows, it means that the snapshot version number or time token of the target workflow has changed within the window period from preview confirmation to application initiation. The system immediately determines that a concurrent conflict has occurred. At this time, no structure write operation is performed, nor is the transaction committed. Instead, a conflict error containing the current latest version number and time token is directly returned to the caller.

[0048] For scenarios where partial memory modifications have been performed but transactions have not yet been committed, the system leverages the atomic rollback capability of database transactions. Upon detecting a version number verification failure, it proactively triggers a transaction rollback instruction, undoing all insert, update, or delete operations within the current transaction. This restores the target workflow in the database to its complete state before application processing began. Throughout the entire expiration protection process, the system does not rely on distributed locks or external coordination services; it relies entirely on the database's own conditional update and transaction mechanisms, thereby ensuring the consistency and integrity of workflow data in high-concurrency environments.

[0049] Furthermore, to ensure the robustness of the expiration protection mechanism in high-concurrency bidirectional creation scenarios, this application's expiration protection mechanism adopts a multi-stage architecture combining "application pipeline event-driven monitoring and database atomicity verification," rather than relying solely on internal database transaction verification. Specifically, when application processing is triggered by manual confirmation, the system first performs a pre-check before the transaction starts: independently querying and retrieving the latest metadata of the target workflow in the current database; if it is inconsistent with the preview baseline, the transaction is directly rejected, achieving early interception; subsequently, during the transaction execution period, the system's monitoring logic is deployed at the application pipeline level, sensing external concurrent modifications through read-only connections or database change event subscriptions independent of the current transaction; finally, at the moment of transaction commit, the database executes condition updates and atomic rollback as a fallback. This multi-stage architecture ensures that application-layer monitoring and the database transaction isolation mechanism do not interfere with each other.

[0050] refer to Figure 5 In step S14, the specific steps are as follows: S141: During real-time monitoring of application processing, if the snapshot version number or last update time token of the target workflow is found to be inconsistent with the preview stage, the current application processing will be forcibly intercepted and all uncommitted intermediate states will be rolled back. S142: After the application processing is successfully completed, reverse serialization is performed on the existing workflow to reverse export the graph structure and node instance state in the engine as a structured description, so that text-oriented editing can be performed directly in the DSL layer. S143: The reverse serialization process preserves the complete topological logic and capability binding snapshot. When an editing instruction for the structured description is received, the system triggers the normalized processing flow of parsing, binding, previewing and confirming again, thereby building a two-way creation event for the workflow.

[0051] In step S141, the specific steps are as follows: At this time, during the application processing of sending the workflow intent to the target workflow entity, the system initiates a real-time monitoring mechanism for the target workflow metadata. This mechanism uses the snapshot version number and last update time token generated in the preview stage and encapsulated in the application handover metadata as a baseline. At each critical transaction node of the application processing, it initiates polling or event listening to the current state of the target workflow in persistent storage or runtime cache. The system performs a strict consistency comparison between the real-time obtained current snapshot version number and last update time token and the above baseline, thereby establishing a highly sensitive concurrent conflict detection barrier in the application pipeline.

[0052] When the real-time monitoring mechanism detects any offset or difference between the current snapshot version number or last update time token of the target workflow and the baseline recorded in the preview stage, the system immediately determines that the target workflow has been affected by external "concurrent operations, such as modifications by other intelligent agents or humans" within the time window from preview confirmation to application delivery. At this time, the system immediately triggers a forced interception command at the logical level, cuts off the execution flow of the current application processing pipeline, freezes all subsequent write operations on the target workflow structure or parameters, and blocks the illegal overwriting of the existing workflow state by expired intentions, thereby ensuring that the consistency of workflow data is not compromised at the runtime level.

[0053] Optionally, during the application processing that sends workflow intents to the target workflow entity, the system initiates a real-time monitoring mechanism for the target workflow metadata. It is important to clarify that this "real-time monitoring" does not involve intruding into database transactions to probe uncommitted states, as this is limited by the isolation properties of database transactions; rather, it is an event-driven monitoring mechanism deployed at the application pipeline level, which runs parallel to and does not conflict with the database transaction isolation mechanism.

[0054] The application pipeline decomposes the application processing into ordered key operation nodes (such as node instance creation, topology reconnection, parameter overriding, etc.). Before each key operation, at the pipeline hook position, it initiates polling of the target workflow's current metadata using a read-only connection independent of the current transaction (based on the latest committed snapshot of the database), or listens for external modifications by subscribing to row-level change notification events in the database. The monitoring mechanism uses the snapshot version number and last update time token generated during the preview phase and encapsulated in the application handover metadata as a baseline. Before each key operation in the application processing, it performs a strict consistency comparison between the real-time acquired current committed state metadata and the aforementioned baseline.

[0055] When the monitoring mechanism detects any offset or difference between the current snapshot version number or last update time token of the target workflow and the baseline recorded in the preview stage, the system immediately determines that the target workflow has been affected by external concurrent operations within the time window from preview confirmation to application delivery. At this time, the system immediately triggers a forced interception command at the application pipeline logic level, cuts off the execution flow of the current application processing pipeline, and freezes all subsequent write operations on the target workflow structure or parameters.

[0056] After successfully intercepting the current application processing, the system initiates a transactional rollback mechanism. Since the application processing may involve multiple steps of node topology modification, parameter overwriting, and connection reconstruction, when the interception is triggered, the system locates the intermediate change records that have been written to the memory cache or temporary persistent layer but have not yet been committed to the final globally visible state. Based on the pre-operation log or event tracing mechanism, the system reverses the order of all the above-mentioned executed local modifications, accurately restoring the runtime representation and temporary storage state of the target workflow in memory to the initial moment before the application processing was initiated. This ensures that the system does not retain any dirty data or residual state caused by conflict interception, thereby maintaining the absolute purity and stability of the workflow engine.

[0057] Optionally, after successfully intercepting the current application processing, the system initiates a transactional rollback mechanism. It should be emphasized that this transactional rollback is not a manual reversal of executed modifications by the application layer, but rather fully utilizes the atomicity of database transactions. The application pipeline directly sends a ROLLBACK instruction to the current database transaction connection, and the database engine reverts all executed but uncommitted modifications within the transaction at the transaction boundary in one go.

[0058] Because application processing may involve multi-step node topology modifications, parameter overwriting, and connection reconstruction, the system, upon interception, only locates the connection handle of the current transaction to send a rollback command, without needing to reverse the process line by line. The database engine automatically reverses all executed operations based on its internal transaction log, restoring the target workflow's state in the database to its initial state before the transaction began. Simultaneously, for intermediate change records written to the application pipeline's memory cache but not yet persisted (such as pre-created node instances, temporary connection caches, and other memory objects not covered by database transactions), the system reverses all such partial modifications based on the pre-operation log or event sourcing mechanism. In other words, database-level modifications are atomically undone by the ROLLBACK command, and application-level memory modifications are reversed by the event sourcing mechanism. These two layers work together to ensure that the system does not retain any dirty data or residual state caused by conflict interception.

[0059] In step S142, the specific steps are as follows: At this point, after executing application processing with expiration protection, the system monitors the execution status of application transactions in real time. When it is confirmed that all workflow intents or patch preview models have been safely delivered to the runtime environment, and the global topology and node attributes of the target workflow have been persistently changed as expected, the system determines that the application processing has been successfully completed. At this time, the system immediately triggers the reverse serialization mechanism, flipping the direction of the data flow from "text to runtime", and starting the backtracking extraction process from runtime entities to structured text, laying the data foundation for the construction of a two-way creation closed loop.

[0060] The reverse serialization engine performs a deep traversal of the existing workflow's runtime instance within the engine. It is important to clarify that, in the context of reverse serialization, the "runtime instance" mentioned in this application specifically refers to the "workflow structure definition and capability binding snapshot" maintained by the workflow engine in persistent storage or memory, rather than the execution context that includes transient execution states (such as manual task suspension states, asynchronous callback tokens, loop iteration counters, error retry counts, temporary values ​​within variable scopes, compensation stack states, etc.).

[0061] Declarative DSLs are essentially blueprint languages ​​describing the static structure and execution constraints of workflows. Their scope is limited in architectural design to node types, topology connections, parameter key-value pairs, and capability binding metadata. The transient and procedural information generated during workflow execution is attached to specific execution instance IDs and runtime memory environments, lacking a reversible mapping to the static text of the declarative DSL. Furthermore, this transient information has no practical value for secondary text-oriented arrangement and bidirectional creation. Therefore, the extraction objects for reverse serialization are strictly limited to: extracting fixed structural definitions and capability binding snapshots one by one, starting from the entry node of the workflow, according to the topology sorting rules of the directed acyclic graph; the extracted content includes the execution component identifier of the node, parameter key-value pairs, input / output port contracts, the spatial layout coordinates of the node on the canvas, and the conditional expressions of branch routes, while actively stripping transient procedural information such as suspended tokens and loop counters.

[0062] The system reconstructs the pure logic and structure data, which has been stripped of the underlying engine's private memory pointers, into a standardized intermediate representation structure decoupled from the engine implementation. It is important to clarify that the so-called "lossless export of runtime semantics" does not refer to exporting the full instantaneous execution state containing temporary variable values ​​and execution breakpoints in the engine's memory, but rather to the lossless export of "workflow structure definitions and capability binding rules."

[0063] Specifically, since Structured DSL is a declarative description language, its syntax tree cannot and should not carry procedural information. Therefore, the reverse serialization process employs an explicit layering strategy for semantic preservation: for the static structure layer (node ​​types, topology connections, layout coordinates) and constraint rule layer (component identifiers for capability binding, parameter enumeration ranges, version dependencies), the system implements strict lossless extraction and export; for the procedural layer (such as the current iteration round, suspended approval status, etc.), the system actively strips it during reverse export, retaining only the loop structure declarations and manual task node declarations at the definition level. Thus, the exported structured description text accurately restores the "full snapshot of the orchestration blueprint and capability constraints" of the existing workflow, rather than a "slice of instantaneous memory during execution." This design aligns with the essential attributes of DSL as an orchestration medium, ensuring that the exported text can be directly used for the next structured parsing and bidirectional creation iteration.

[0064] Based on the aforementioned standardized intermediate representation structure, the system performs formatted mapping and text reconstruction operations, reversibly exporting the runtime graph structure and node instance states into a standardized descriptive text conforming to the preset structured DSL syntax, namely CanonicalDSL representation. This structured descriptive text, in a compact and self-contained form, accurately restores the current full runtime semantics of the existing workflow. As a result, external AI agents or human operators can directly perform text-oriented editing operations such as adding, deleting, modifying, and querying in plain text form at this DSL layer. The edited text can then re-enter the parsing, binding, and preview pipeline, thereby completely opening up the reverse channel from runtime entities to text creation media and constructing a complete two-way creation closed loop.

[0065] In step S143, the specific steps are as follows: At this point, when the system performs reverse serialization to generate structured description text, it implements a strict semantic preservation strategy. This strategy ensures that the exported structured description not only includes the static node and connection declarations of the workflow, but also embeds the metadata snapshots, parameter constraint rules, and data flow and control flow topology logic generated after capability binding during runtime into the text structure in the form of annotation attributes or hidden fields. As a result, the structured description text becomes a self-contained carrier carrying the complete runtime context, ensuring that the semantic boundaries and execution constraints of the workflow do not suffer any information decay or silos during the conversion from runtime instance to text medium.

[0066] Optionally, the structured description text becomes a self-contained carrier of the complete structural definition and capability constraint context. It is important to emphasize that the "complete runtime context" here refers to the "capability binding snapshot and topology baseline" captured and solidified by reverse serialization. This allows the DSL text to move beyond its initial state of merely declaring intent and acquire self-verification capabilities including validation rules and component dependencies. In contrast, the transient execution context of the workflow (such as runtime variable storage and compensation stack states) lacks a mapping to declarative text and is not within the scope of the reverse serialization in this application; its lifecycle management remains with the underlying workflow engine. Therefore, during the conversion from runtime instances to text media, the semantic boundaries of the workflow at the structural and constraint layers do not experience information decay. This maintains the system's strong constraint characteristics in a text-oriented editing environment while avoiding the technical impracticality of attempting to forcibly DSL-ize transient states.

[0067] When an external AI agent or human reviewer initiates a text-oriented editing instruction based on the above structured description, the system captures the incremental modification event in real time through the text listening interface. After the system recognizes that the current operation object is DSL text carrying a full-bound snapshot, it immediately re-injects the latest edited text stream into the beginning of the processing pipeline, triggering the complete normalized processing flow from parsing to confirmation again. This re-triggering mechanism treats the reverse-guided text and the input of forward creation as isomorphic, ensuring that whether it is a new intention or a secondary modification based on the existing process, it must unconditionally pass the grammatical validity verification and semantic security verification, thereby maintaining the system's strong constraint characteristics in an open text editing environment.

[0068] The system sequentially performs lexical and syntactic parsing on the re-injected text to generate standardized DSL text. Based on the built-in capability binding snapshot and the latest capability list, it performs deep capability mapping and semantic verification, converts it down into structured runtime intent, and generates a read-only preview view in the sandbox. After the preview result is manually confirmed, the system performs application processing with expiration protection again. This entire process connects the two reverse operation flows of "exporting runtime instance to text" and "submitting text modification to runtime" in logic and timing, enabling the workflow system to perform lossless and reversible round-trip iterations between the graphical runtime and the structured text medium, thus formally constructing a closed-loop workflow bidirectional creation event.

[0069] The expiration protection mechanism described in this application operates with a multi-stage verification architecture in each round of the bidirectional creation event: pre-checking and interception before the transaction begins; proactively interrupting external concurrent modifications during transaction execution through the application pipeline event-driven mechanism; ensuring eventual consistency through database condition updates at transaction commit; and collaboratively restoring the system through database atomic rollback and application-layer event tracing after a conflict. This mechanism organically combines the short-transaction characteristics of optimistic concurrency control with the ability to perceive concurrency throughout the entire application processing lifecycle. It avoids long-term occupation of database resources by long transactions and overcomes the limitation of database transaction isolation in its inability to detect external modifications in real time during transaction execution, thereby ensuring the consistency and integrity of workflow data in high-concurrency bidirectional creation scenarios.

[0070] Specific application scenarios and corresponding implementation methods of this application: In step S111, the implementation uses the logiflow-cli command toolchain as the implementation carrier. The system first receives an operation request for the target workflow. The operator enumerates all available workflow targets from persistent storage or the runtime environment through the target list query command, accurately locates the target entity according to the display name, and obtains its globally unique target workflow identifier. Then, through the workflow current state read command, the complete context information of the target workflow is extracted. This context information is structured and defined as at least four elements: the target workflow identifier is used to globally and uniquely index the current operation entity; the snapshot version number is used to mark the structural baseline of the current workflow, which is automatically incremented by the system whenever any attribute of the workflow changes; finally, the update time token serves as the basic credential for optimistic concurrency control, with a timestamp accurate to the millisecond level, which is automatically written by the storage layer when each update operation is triggered; the current capability list includes the capability catalog and parameter constraints of all available nodes in the current workflow runtime environment; the context information may also optionally include the current workflow snapshot, providing a complete anchoring benchmark for subsequent rewriting of existing processes.

[0071] After obtaining the context information, the system injects the current capability list and target workflow identifier as context constraints into the external intelligent terminal. Under this constraint, the external intelligent terminal abandons the fuzzy inference of free natural language and strictly generates the corresponding workflow DSL text according to the preset structured DSL syntax specification. This text contains core semantic paragraphs such as workflow header, status, entry, plan diagram, execution and data description, layout, and branch definition, and may contain optional rewrite paragraphs. The rewrite paragraphs are used to declare the anchor points and replacement scope of local rewrites in the existing workflow rewrite scenario. The entire DSL text adopts a text format that combines human-readable and machine-parsable key-value pairs with hierarchical indentation, without natural language comments or unstructured descriptions, so that the parser can complete the parsing with only finite state machines and context-free grammars, without relying on external semantic libraries or artificial intelligence models. The generated workflow DSL text, as a pure character stream, is directed to the DSL parser, which in practice calls dialect formatting commands and triggers the lexical and syntactic parsing process.

[0072] In step S112, after the DSL parser receives the workflow DSL text character stream, it first triggers the lexical analysis stage. In this stage, according to the preset DSL lexical rules, the input character stream is converted into a token sequence with definite lexical attributes through a finite state machine. During this process, the parser simultaneously performs a redundancy stripping operation to selectively filter out annotation information without semantic support, such as descriptive annotations, as well as format differences such as irregular indentation, redundant blank lines, and non-standard whitespace characters. This ensures that the input information is reduced from free text form to a token stream composed purely of core lexical units, thereby eliminating the interference of differences in expression habits when the external intelligent terminal generates text on the subsequent grammatical structure.

[0073] After acquiring the token stream, the parser enters the syntactic analysis phase. Based on the context-free grammar of the DSL or its extended production rules, it reduces and derives the token stream, verifies the legality of the grammatical structure, and maps the token stream into a compact workflow intermediate representation. This intermediate representation is preferably a stable directed abstract syntax tree or attribute graph structure. Logically, it strictly preserves the core semantic nodes such as workflow head, state, entry, plan graph, branch definition, and rewritten segment, as well as their hierarchical subordination and topological connection relationships, and removes the linear arrangement features of the original text to form an in-memory computing model that is easy for machines to traverse, query, and modify.

[0074] After successfully constructing the intermediate representation, the parser triggers the reverse serialization mechanism, traversing the semantic nodes and topological edges of the intermediate representation. Strictly following the preset standard DSL typesetting specifications, it regenerates a standardized DSL text with a unified indentation level, standardized line break rules, and a unified bracket delimiter style. This standardized text is semantically equivalent to the original input text, but eliminates any personalized writing style, providing a stable and predictable text baseline for subsequent capability binding verification, multi-round editing, and manual review.

[0075] In step S113, during the process of the parser converting the workflow DSL text into a compact intermediate representation, a syntax structure validity inspection mechanism is triggered simultaneously. This mechanism performs a deep traversal of the constructed abstract syntax tree or graph model and performs multiple types of core checks against preset syntax constraint rules: the first is field duplication detection, which identifies whether the same step alias or parameter key name is declared in the same level or scope; the second is segment missing detection, which verifies whether the text is missing semantic segments that must be present, such as workflow header, entry point, and plan diagram.

[0076] When any grammatical error is detected during the inspection process, the parser immediately triggers an interruption exception, abandoning all downstream operations such as subsequent semantic analysis, intermediate representation improvement, and normalized text reconstruction that are currently being executed. This prevents the current text from entering the capability binding and preview application stage. This immediate interruption mechanism forcibly intercepts illegal input at the front end of the parsing pipeline, preventing structurally flawed intermediate representations from flowing downstream and causing unpredictable logical failures or system state pollution.

[0077] While interrupting the generation process, the parser locates the grammatical node that triggers the error and extracts its positional metadata in the original text, including at least the starting line number, column number, ending line number, and column number of the error, or identification information of the semantic paragraph where the error is located. The parser encapsulates the error type, error description, and positional metadata in a structured manner, generates structured diagnostic information, and outputs it to the outside world, providing precise error anchors for external intelligent terminals or human reviewers, thereby achieving fine-grained and traceable grammatical-level interception at the input end.

[0078] In step S121, after obtaining the parsed and generated normalized DSL text, the system triggers a deep traversal mechanism to access each workflow node declared in the plan diagram and execution description one by one along the topological logic of the abstract syntax tree or compact intermediate representation. During the traversal, the system accurately extracts the core elements of the current node, including at least the step alias used for logical addressing, the node type used to define the execution logic, and the parameter information used to configure runtime behavior, including parameter key names and parameter values, providing a complete data source to be bound for subsequent mapping and comparison.

[0079] In implementation, this stage corresponds to the capability context query command and resource list query command: The system first pulls the available node capability directory for the target workflow, and then drills down to query the parameter definition, port specifications and value constraints of the specific node type referenced in the DSL; at the same time, it obtains the resource list of variables, input and output signals, motion points and camera resources, and queries the type definition and executable operations of specific resources; the system initiates mapping and matching of the extracted node core elements to the preset capability list: comparing the node type with the capability directory to establish the classification, anchoring the step alias with the unique identifier in the capability directory, and matching the parameter information with the description information under the corresponding type item by item, thereby transforming the declarative nodes in the text into semantically related entities with clear runtime execution directions at the logical level.

[0080] After a successful mapping match, the system generates a semantic association annotation for the runtime instance of the current node, dynamically attaching the corresponding underlying execution component identifier, port constraint definition, and parameter default value rules from the capability list to the intermediate representation node. Through this stage, the workflow node, which originally only had text declaration attributes, is given a precise backend execution semantic and scheduling boundary. The workflow intent is upgraded from a static structured text description to a runtime instance model that can be directly recognized and scheduled by the workflow engine, completing the closed loop of deep capability binding.

[0081] In step S122, the system synchronously triggers a semantic-level verification mechanism during the mapping process. Using the capability catalog and description information as the gold standard, it performs a deep constraint comparison on the mapped object, focusing on examining multiple types of semantic-level errors: first, capability missing, i.e., the node type cannot find a matching item in the capability catalog; second, capability unavailable, i.e., although the node type exists, its current state is marked as disabled or beyond the permitted range; third, attribute unsupported, i.e., the parameter key name declared by the node is not defined in the description information of the corresponding capability; fourth, attribute value invalid, i.e. although the parameter key name is legal, the input value violates the data type, enumeration range, or logical constraints specified in the description information. The comparison and mapping operations are executed atomically within the same traversal cycle to ensure the real-time nature of semantic verification.

[0082] In implementation, the system executes dialect-based verification commands during the static verification phase to complete a two-dimensional check of structure and semantics; while the final capability binding for specific live targets is left to be executed again in the preview phase in combination with the target context, forming a two-level verification architecture.

[0083] When any semantic-level error is identified during the verification process, the system immediately interrupts the current traversal mapping operation and triggers the process blocking mechanism. At the logical level, it directly cuts off the transmission channel of the current text to the downstream conversion stage, freezes any preview and application operations for the target workflow, and intercepts semantic defects that violate runtime capability constraints before the business logic takes effect. At the same time, the system extracts the context information of the node that triggered the error, generates a structured semantic-level blocking record, and outputs it externally. The record includes at least the alias of the step where the error occurred, the error type identifier, the expected constraint description extracted from the capability list, and the actual conflict content in the current text that caused the verification failure. This blocking record provides clear self-reflection basis for external intelligent terminals or human reviewers, supporting them to make precise targeted corrections at the DSL layer and complete the closed loop of semantic-level interception and error correction.

[0084] In step S123, the system monitors the mapping status in real time during the deep capability binding and semantic-level verification process; when all nodes have been traversed and no semantic-level error blocking has been triggered, the system generates and outputs mapping pass information; upon receiving this information, the system immediately triggers the metadata reverse writing mechanism, marking the transformation of the text from the static declaration stage to the runtime complete declaration stage.

[0085] Based on the established mapping relationship, the system makes the implicit constraint information in the capability list explicit and writes it back to the corresponding node attributes of the normalized DSL text. The back-writing operation includes three dimensions: first, metadata back-writing, which writes the underlying execution component identifier, input / output port specifications, and runtime resource quota corresponding to the node type into the node; second, parameter constraint back-writing, which appends the default value of the parameter, data type limit, enumeration range, and mandatory validation rules to the parameter declaration of the node; and third, version dependency back-writing, which injects the runtime environment version, minimum compatible version of the component library, and other dependencies on which the node execution depends into the workflow header or node metadata. After this back-writing, the normalized text is enhanced into a full text carrying the complete runtime context.

[0086] After the reverse writing is completed, the system generates a fully bound verification record based on the enhanced full text. This record not only includes a summary of the workflow's topology but also embeds the reversed parameter constraint rules and version dependency baseline as verification credentials into the text. As a result, the text itself carries a complete set of rules for determining the legality of subsequent modifications, possessing runtime semantic expression and self-verification capabilities. In subsequent bidirectional editing, any incremental modification can be self-verified locally based on the embedded constraint rules, eliminating the need for frequent requests to external capability lists and significantly improving the real-time performance and security of bidirectional creation.

[0087] In step S131, the system obtains the full binding verification record generated in the previous step and uses it as a credit certificate for the semantic completeness of the standardized text. The system extracts the mapping through state and reverse writing constraint information encapsulated in it to confirm that the current text has a complete runtime semantic expression, providing a safe and semantically closed input source for structured downconversion and preventing unbound or semantically incomplete text from entering the intent extraction pipeline.

[0088] During the conversion process, the system performs abstraction and dimensionality reduction operations on the normalized text, selectively stripping away the underlying syntactic features that exist only to meet human readability or intelligent device generation habits, including redundant text separators, hierarchical indentation marks, annotation fragments, domain keyword declarations, and text connectors between node declarations. By removing the above-mentioned syntactic sugar and format packaging that only serve text representation, the system degrades the declarative structure of the plain text form into a decontextualized graph topology that retains only the core logical flow and data mapping relationship.

[0089] While stripping away the underlying grammatical features, the system extracts structured runtime intents from the dimensionality-reduced structure based on the metadata and parameter constraints written backwards in the verification records: mapping node types to execution component identifiers that the engine can recognize, converting parameter information into input-output data contracts that meet the requirements of strong runtime typing, and converting topological connections into directed edge-driven sequences that the engine scheduler can parse; the resulting runtime intents, as intermediate data structures decoupled from specific grammars, can be directly loaded and driven by the workflow engine; in practice, this transformation is completed by the target-oriented preview command in its internal transformation stage, that is, from the normalized DSL to the graph intermediate representation.

[0090] In step S132, after the system transmits the structured runtime intent to the preview pipeline, it immediately starts a real-time monitoring mechanism to build a sandbox isolation space independent of the production environment during the preview stage, and monitors the entire lifecycle of the runtime intent parsing and rendering process. The system intercepts any instruction that attempts to cross the preview boundary and directly initiate a write request to the target workflow in persistent storage, ensuring the absolute read-only nature of the preview process and preventing irreversible pollution of existing workflows caused by misoperation or unauthorized access at both physical and logical levels.

[0091] The system performs multi-dimensional data extraction and reorganization based on the current workflow intent to be previewed, generating a structured preview view. This view consists of four core elements: First, a processing summary, which extracts node topology changes, the number of capability calls, and key parameter adjustments to form a macro overview for quick human review; second, compact text, which reverse-serializes the runtime intent into its simplest form, removing redundant whitespace and comments, for external intelligent terminals to perform low-context-burden logical comparison; third, diagnostic information, which summarizes the semantic pass status in the preceding verification records and the simulated operation warnings in the preview stage to form a complete health assessment report; and fourth, application handover metadata, which encapsulates the version baseline, snapshot identifier, last update time token, intent hash value, source code verification value, capability verification value, and resource verification value of the current workflow intent into an immutable handover credential, providing a security anchor for subsequent application processing.

[0092] Throughout the entire process of generating and outputting the preview view, the system uses database transaction isolation mechanisms and memory snapshot technology to ensure that the generation operation is executed only in an independent copy or memory mapping. The original data structure, node connections, and parameter configurations of the target workflow in the storage medium remain absolutely static and untouched. This read-only protection mechanism strongly isolates intent review and entity modification in terms of time and space, so that any intelligent generation intent that has not been finally confirmed by a human cannot have a substantial impact on the production environment.

[0093] In step S133, the system performs real-time detection of the text's structural paragraphs in the preview pipeline. When it detects that the text contains optional rewrite paragraph declarations, it immediately triggers a mode switching mechanism, adaptively mapping the creation mode from the full new creation mode to the existing workflow rewrite mode. In this mode, the system no longer treats the text as an independent and complete new creation process, but instead parses it into an incremental modification instruction set for the existing runtime workflow, establishing a mapping between local modifications and the global existing context.

[0094] After the system enters rewrite mode, it deeply analyzes the anchor identifier declared in the rewrite segment. This identifier uniquely specifies the target logical node or connection range to be rewritten in the existing workflow. Based on this identifier, the system extracts a local subgraph from the persistently stored complete snapshot of the existing workflow, with the anchor node as the core and containing its direct upstream and downstream data dependencies and control dependencies. This shrinks the huge global topology into a finite local range, providing the scope boundary for accurate rewriting.

[0095] The system overwrites or inserts the new logical structure declared in the rewritten section into the extracted local subgraph, replacing the original logic pointed to by the anchoring identifier, and performs an anchored local rewrite preview. During the process, the system uses a topology comparison algorithm to calculate the port type changes, data flow redirection, and upstream and downstream dependency path changes caused by the rewrite operation, and transforms the change trajectory into highlighted marks or difference connection lines for visual rendering in the preview view. This intuitively shows the impact of the rewrite operation on the existing workflow, providing a clear decision basis for manual review.

[0096] Once the partial rewrite preview has been manually reviewed and confirmed to be correct, the system receives the manual confirmation instruction and executes entity application processing based on the application handover metadata. The system extracts the snapshot version number and last update time token carried in the metadata and initiates a conditional update comparison with the storage layer using the target workflow identifier as the primary key. If the two are completely consistent with the actual values ​​in the current persistent storage, it is determined that the target workflow has not been modified by a third party during the preview period, and the system securely distributes the rewrite intent to the application. If the determination is inconsistent, the expiration protection mechanism is triggered, the current application processing is forcibly intercepted, the target expiration result is returned, and a re-initiation of the check and preview is required, completely eliminating data overwriting and logical conflicts caused by concurrent rewrites from multiple terminals.

[0097] In step S141, during the application processing of the target workflow entity, the system initiates a real-time monitoring mechanism for the target workflow metadata. It should be clarified that this real-time monitoring does not intrude into the database transaction to explore the uncommitted state, but is an event-driven monitoring mechanism deployed at the application pipeline level, which runs in parallel with the database transaction isolation mechanism and does not conflict with it.

[0098] The application pipeline decomposes the application processing into ordered critical operation nodes, such as node instance creation, topology reconnection, and parameter overriding. Before each critical operation is executed, at the pipeline hook position, it initiates a polling of the target workflow's currently committed metadata via a read-only connection independent of the current transaction, or listens for external modifications by subscribing to row-level change notification events in the storage layer. The monitoring mechanism uses the snapshot version number and last update time token encapsulated in the application handover metadata during the preview phase as a baseline. Before each critical operation, it performs a strict consistency comparison between the real-time acquired current committed state and the baseline, thereby establishing a highly sensitive concurrency conflict detection barrier in the application pipeline.

[0099] When the monitoring mechanism detects any offset or difference between the current snapshot version number or time token and the baseline, the system immediately determines that the target workflow has been affected by external concurrent operations within the time window from preview confirmation to application delivery. At the application pipeline logic level, a forced interception command is immediately triggered to cut off the execution flow of the current application processing pipeline and freeze all subsequent write operations on the target workflow structure or parameters.

[0100] Upon successful interception, the system initiates a transactional rollback mechanism. This rollback is not a manual reversal of modifications at the application layer, but rather fully utilizes the atomicity of transactions in the storage layer. The application pipeline sends a rollback command to the current transaction connection, and the database engine, based on the internal transaction log, reverts all executed but uncommitted modifications at the transaction boundary, restoring the target workflow to its initial state before the transaction began. Simultaneously, for intermediate change records written to the application pipeline's memory cache but not yet persisted, such as pre-created node instances and temporary connection caches—memory objects not covered by database transactions—the system reverses all local modifications based on the pre-operation log or event sourcing mechanism. The database layer and the application memory layer work together to ensure that the system does not retain any dirty data or residual state caused by conflict interception, maintaining the absolute purity and stability of the workflow engine.

[0101] Furthermore, to ensure the robustness of the expiration protection mechanism in high-concurrency bidirectional creation scenarios, this implementation adopts a multi-stage architecture combining application pipeline event-driven monitoring and database atomicity verification: before a transaction begins, a pre-check interception is performed by independently querying and extracting the latest metadata; if it is inconsistent with the preview baseline, the transaction is directly rejected; during transaction execution, the application pipeline detects external concurrent modifications through read-only connections or change event subscriptions; finally, at the moment of transaction commit, database condition updates and atomic rollback are used as a fallback, and the version number is checked again before committing to ensure it has not been changed by other transactions; the entire expiration protection process does not rely on distributed locks or external coordination services, which avoids long-term occupation of database resources by long transactions and overcomes the limitation of difficulty in detecting external modifications in real time during transaction execution under transaction isolation.

[0102] In step S142, the system monitors the execution status of application transactions in real time. When it is confirmed that all workflow intentions have been safely sent to the runtime environment and the global topology and node attributes of the target workflow have been persistently changed as expected, the application processing is determined to be successfully completed. At this time, the system immediately triggers the reverse serialization mechanism to reverse the data flow direction from text to runtime and start the backtracking extraction process from runtime entities to structured text. In practice, the operator can read the live workflow after the application again through the current status of the workflow or the online inspection command. The strict capture and reverse structure verification are automatically executed by the host.

[0103] The reverse serialization engine performs a deep traversal of the existing workflow's runtime instances within the engine. It's important to clarify that the runtime instances referred to here specifically refer to snapshots of the workflow structure definitions and capability bindings maintained by the workflow engine in persistent storage or memory, rather than execution contexts containing transient execution states. Transient execution states include manual task suspension states, asynchronous callback tokens, loop iteration counters, error retry counts, temporary values ​​within variable scopes, compensation stack states, etc. Declarative text is essentially a blueprint language describing the workflow's static structure and execution constraints. Its scope is limited in the architectural design to node types, topology connections, parameter key-value pairs, and capability binding metadata. Transient process state information is attached to specific execution instances and runtime memory environments, lacks a reversible mapping relationship to declarative text, and has no practical value for secondary text-oriented orchestration.

[0104] Therefore, the objects extracted by reverse serialization are strictly limited to: based on the topological sorting rules of the directed acyclic graph, starting from the entry node of the workflow, extracting the fixed structural definitions and capability binding snapshots one by one. The extracted content includes the execution component identifier of the node, parameter key-value pairs, input and output port contracts, spatial layout coordinates of the node on the canvas, and conditional expressions of branch routes, while actively stripping instantaneous process state information such as suspended tokens and loop counters, retaining only the loop structure declarations and manual task node declarations at the definition level.

[0105] The system reconstructs the pure logic and structure data, stripped of the engine's private memory pointers, into a standardized intermediate representation structure decoupled from the engine implementation. Based on this structure, it performs formatting mapping and text reconstruction operations, reversibly exporting the runtime graph structure and node instance states into standard descriptive text that conforms to the preset structured syntax specifications. This text, in a compact and self-contained form, accurately restores the existing workflow's orchestration blueprint and a full snapshot of capability constraints, rather than a momentary memory slice during execution. This layered semantic preservation strategy ensures that the exported text can be directly used for the next structured parsing and bidirectional creation iteration, avoiding the technical impracticality caused by forcibly textualizing the transient state.

[0106] In step S143, the system implements a strict semantic preservation strategy when performing reverse serialization to generate structured description text: the exported description not only includes the static node and connection declarations of the workflow, but also embeds the metadata snapshots, parameter constraint rules, and data flow and control flow topology logic generated after capability binding during runtime into the text structure in the form of annotation attributes or hidden fields; thus, the structured description text becomes a self-contained carrier carrying the complete structural definition and capability constraint context, and has the self-verification capability of including verification rules and component dependencies; while the instantaneous execution context of the workflow does not have a mapping relationship to the declarative text and does not belong to the export category, its lifecycle management still belongs to the underlying workflow engine itself; in the process of conversion from runtime instance to text medium, the semantic boundaries of the workflow at the structure layer and constraint layer do not experience any information decay or silos.

[0107] When an external AI agent or human reviewer initiates a text-oriented editing command based on the above structured description, the system captures the incremental modification event in real time through the text listening interface. After recognizing that the current operation object is text carrying a full-bound snapshot, the system immediately re-injects the latest edited text stream into the beginning of the processing pipeline, triggering the complete normalization process from parsing to confirmation again: lexical and syntactic parsing is executed sequentially to generate normalized text; deep capability mapping and semantic verification are performed based on the built-in capability-bound snapshot and the latest capability list; the text is down-converted into a structured runtime intent and a read-only preview view is generated in the sandbox; after the preview result is manually confirmed, application processing with expiration protection is executed again. This re-triggering mechanism treats the reverse-guided text and the input of the forward creation as isomorphic, ensuring that whether it is a newly created intent or a secondary modification based on an existing process, it must unconditionally pass grammatical validity verification and semantic security verification, maintaining the system's strong constraint characteristics in an open text editing environment.

[0108] For scenarios involving the creation of new top-level workflows, this implementation adopts a guided preview path instead of target discovery and locking: instead of querying the target list and existing target identifiers, the text source file, dialect, source identity identifier, workflow name, and naming strategy are directly specified by the guided preview command. The identity and naming constraints of the new workflow are established in the preview stage, and its subsequent handoff generation, confirmation application, and expiration protection mechanisms are consistent with those in the editing scenario.

[0109] Thus, the two reverse operation flows of exporting runtime instances to text and sending text modifications to runtime are logically and temporally connected. The workflow system can perform lossless and reversible round-trip iterations between the graphical runtime and the structured text medium. The expiration protection mechanism described in this application operates in each round-trip with a multi-stage verification architecture, including pre-transaction interception, event-driven perception during transaction execution, condition update as a fallback when the transaction is committed, database rollback after conflict, and collaborative recovery through application-layer event tracing. This formally constructs a closed-loop, high-concurrency, and secure bidirectional workflow creation event.

[0110] Please see Figure 6 The bidirectional authoring system based on structured DSL workflow is applied to the aforementioned bidirectional authoring method based on structured DSL workflow; the bidirectional authoring system based on structured DSL workflow includes: Text module 21 is used to acquire the target workflow, determine the corresponding workflow DSL text by combining it with the preset structured DSL, and input the workflow DSL text into the DSL parser; the DSL parser parses the workflow DSL text and generates a normalized DSL text; The verification module 22 is used to bind the normalized DSL text to the capability, map the step aliases, node types and parameter information of the normalized DSL text to the preset capability list, perform semantic-level verification on the normalized DSL text during the mapping process, and output the corresponding verification record. Application module 23 is used to convert the verification records and normalized DSL text into structured workflow intents, generate corresponding application handover metadata during the preview stage of the workflow intents, and perform application processing with expiration protection on the target workflow based on the application handover metadata. The bidirectional authoring module 24 is used to forcibly intercept the current application processing if a change is detected in the target workflow during application processing; if the application is completed, it performs reverse serialization on the existing workflow, outputs a structured description of the current workflow, and directly edits it in the DSL layer to construct the bidirectional authoring event of the workflow.

[0111] It should be noted that although multiple modules are mentioned in the detailed description above, this division is not mandatory; in fact, according to the embodiments of this disclosure, the features and functions of two or more modules or described above can be embodied in one module; conversely, the features and functions of one module described above can be further divided into multiple modules to be embodied.

[0112] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the disclosure herein; this application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein; the specification and embodiments are to be considered exemplary only.

[0113] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention; therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A bidirectional authoring method based on a structured DSL workflow, characterized in that, include: Obtain the target workflow and determine the corresponding workflow DSL text by combining it with the preset structured DSL, and input the workflow DSL text into the DSL parser; The DSL parser parses the workflow DSL text and generates normalized DSL text; Capability binding is performed on the normalized DSL text, mapping the step aliases, node types, and parameter information of the normalized DSL text to a preset capability list. During the mapping process, semantic-level verification is performed on the normalized DSL text, and the corresponding verification records are output. The verification records and normalized DSL text are converted into structured workflow intents, and corresponding application handover metadata is generated during the preview stage of the workflow intents. Based on the application handover metadata, application processing with expiration protection is performed on the target workflow. If a change to the target workflow is detected during application processing, the current application processing will be forcibly blocked. Once the application is complete, reverse serialization is performed on the existing workflow to output a structured description of the current workflow, which can then be edited directly at the DSL layer to construct bidirectional authoring events for the workflow.

2. The bidirectional authoring method based on a structured DSL workflow according to claim 1, characterized in that, The process involves acquiring the target workflow, determining the corresponding workflow DSL text by combining it with a preset structured DSL, and inputting the workflow DSL text into the DSL parser. The DSL parser parses the workflow DSL text and generates normalized DSL text, including: The target workflow is obtained, which includes the target workflow identifier, snapshot version number, last update time token, and current capability list. Under the influence of context constraints, the external intelligent terminal determines the corresponding workflow DSL text based on the preset structured DSL. The workflow DSL text includes workflow header, status, entry, plan diagram, execution and data description, layout, branches, and optional rewrite sections, and inputs it into the DSL parser.

3. The bidirectional authoring method based on a structured DSL workflow according to claim 2, characterized in that, The process involves acquiring the target workflow, determining the corresponding workflow DSL text by combining it with a preset structured DSL, and inputting the workflow DSL text into the DSL parser. The DSL parser parses the workflow DSL text and generates normalized DSL text, and also includes: The DSL parser performs lexical and syntactic analysis on the workflow DSL text, parses it into a compact intermediate workflow representation that eliminates redundant comments and format differences, and reconstructs a standardized DSL text with a unified output format accordingly. During this parsing phase, if a syntax error such as duplicate fields or missing segments is detected, the DSL parser immediately interrupts the generation process and outputs structured diagnostic information of the location metadata, thereby achieving syntax-level interception at the input end.

4. The bidirectional authoring method based on a structured DSL workflow according to claim 1, characterized in that, The process of binding the normalized DSL text with execution capabilities maps the step aliases, node types, and parameter information of the normalized DSL text to a preset capability list. During the mapping process, semantic-level validation is performed on the normalized DSL text, and corresponding validation records are output, including: Deep capability binding is performed on the normalized DSL text. By traversing the step aliases, node types and parameter information of each node, it maps them to the capability directory and description information in the preset capability list to complete the semantic association of runtime instances.

5. The bidirectional authoring method based on a structured DSL workflow according to claim 4, characterized in that, The process of binding the normalized DSL text with execution capabilities, which maps the step aliases, node types, and parameter information of the normalized DSL text to a preset capability list, performs semantic-level verification on the normalized DSL text during the mapping process, and outputs the corresponding verification records, also includes: Semantic-level verification is performed synchronously during the mapping process. If a semantic-level error occurs in the capability list, the subsequent processing flow is directly blocked, and a semantic-level blocking record is generated. If the mapping pass information is received, the metadata, parameter constraints, and version dependency information in the capability catalog are written back to the normalized DSL text, thereby generating a fully bound verification record, so that the workflow DSL text has complete runtime semantic expression and self-verification capabilities.

6. The bidirectional authoring method based on a structured DSL workflow according to claim 1, characterized in that, The process of converting verification records and normalized DSL text into structured workflow intents, generating corresponding application handover metadata during the workflow intent preview phase, and performing application processing with expiration protection on the target workflow based on the application handover metadata includes: The verification record is obtained and converted in conjunction with the normalized DSL text. In the process of conversion, the underlying syntactic features of the normalized DSL text are stripped away, and the structured runtime intent is extracted. This runtime intent can directly drive the workflow engine to execute.

7. The bidirectional authoring method based on a structured DSL workflow according to claim 6, characterized in that, The process of converting verification records and normalized DSL text into structured workflow intents, generating corresponding application handover metadata during the workflow intent preview stage, and performing application processing with expiration protection on the target workflow based on the application handover metadata also includes: During the real-time monitoring of the runtime intent preview stage, a preview view containing a processing summary, compact DSL text, diagnostic information, and application handover metadata is generated based on the workflow intent. At this time, the read-only principle is followed, and the target workflow is never directly modified. When a rewritten segment is detected in the workflow DSL text, the current authoring mode is mapped to an existing workflow rewrite. Based on the anchoring identifier in the rewritten segment, a local subgraph of the existing workflow is extracted, and an anchored local rewrite preview is performed to visually demonstrate the impact of the rewrite. After manual confirmation, application processing with expiration protection is performed based on the last update time token carried in the application handover metadata.

8. The bidirectional authoring method based on a structured DSL workflow according to claim 1, characterized in that, During application processing, if a change to the target workflow is detected, the current application processing is forcibly intercepted; if the application is completed, the existing workflow is reverse-serialized, a structured description of the current workflow is output, and editing is performed directly at the DSL layer to construct bidirectional authoring events for the workflow, including: If, during real-time monitoring of application processing, the snapshot version number or last update time token of the target workflow is found to be inconsistent with the preview stage, the current application processing will be forcibly intercepted, and all uncommitted intermediate states will be rolled back.

9. The bidirectional authoring method based on a structured DSL workflow according to claim 8, characterized in that, During application processing, if a change to the target workflow is detected, the current application processing is forcibly intercepted; if the application is completed, the existing workflow is reverse-serialized, a structured description of the current workflow is output, and editing is performed directly at the DSL layer to construct a bidirectional authoring event for the workflow, which also includes: Once the application has successfully completed its processing, the existing workflow is reverse-serialized to export the graph structure and node instance states from the engine into a structured description, which can then be directly edited in a text-oriented manner at the DSL layer. The reverse serialization process preserves the complete topological logic and capability binding snapshot. When an editing instruction for the structured description is received, the system triggers the normalized processing flow of parsing, binding, previewing, and confirmation again, thereby building a two-way creation event for the workflow.

10. A bidirectional authoring system based on a structured DSL workflow, characterized in that, The bidirectional authoring system based on structured DSL workflow is applied to the bidirectional authoring method based on structured DSL workflow as described in any one of claims 1-9; The bidirectional authoring system based on a structured DSL workflow includes: The text module is used to acquire the target workflow and determine the corresponding workflow DSL text by combining it with the preset structured DSL. The workflow DSL text is then input into the DSL parser. The DSL parser parses the workflow DSL text and generates a normalized DSL text. The verification module is used to bind the capabilities of the normalized DSL text, mapping the step aliases, node types and parameter information of the normalized DSL text to a preset capability list. During the mapping process, semantic-level verification is performed on the normalized DSL text and the corresponding verification record is output. The application module is used to convert verification records and normalized DSL text into structured workflow intents, generate corresponding application handover metadata during the preview stage of the workflow intents, and perform application processing with expiration protection on the target workflow based on the application handover metadata. The bidirectional authoring module is used to forcibly intercept the current application processing if a change is detected in the target workflow during application processing; if the application is completed, it performs reverse serialization on the existing workflow, outputs a structured description of the current workflow, and directly edits it at the DSL layer to construct the bidirectional authoring event of the workflow.

Images