@josephyan/qingflow-app-builder-mcp 1.1.25 → 1.1.26

package/skills/qingflow-app-builder/references/complete-system-development-guide.md

@@ -1,172 +0,0 @@
-# Complete System Development Guide
-
-Use this when the user asks for a system, app package, workspace module set, or several related apps/forms.
-Do not compress several business objects into one app.
-
-## Recommended Completeness
-
-Required:
-
-- package exists or is created through `package_apply`
-- core business objects are modeled as separate apps
-- all new apps are created in one multi-app `app_schema_apply(package_id=..., apps=[...])`
-- every app has stable `client_key`, `app_name`, `icon`, `color`, and one readable `as_data_title: true`
-- no app creates platform system fields such as `数据ID`, `编号`, `申请人`, `申请时间`, `创建人`, `创建时间`, `提交人`, `提交时间`, `更新时间`, `更新人`, `当前流程状态`, `当前处理人`, `当前处理节点`, or `流程标题`
-- same-call relations use `target_app_ref` to point to another `apps[].client_key`
-- basic operating views exist for each core app
-- package/apps/fields/relations are read back before repair or retry
-
-Strongly recommended:
-
-- cross-app relation fields for the main business links
-- 1-3 concrete business buttons on core operating views through `app_views_apply.action_buttons`
-- core metric charts and BI charts using semantic `metric`, `metrics`, `group_by`, and `where`
-- a standard portal: business entry area, core metrics, BI charts, then concrete data views
-- portal grid/business-entry sections contain real `config.items[]`, not empty containers
-
-Workflow preflight:
-
-- If an app will have approval/fill/copy workflow nodes, create an explicit business status `select` field in schema first, such as `状态`, `处理状态`, `审批状态`, `工单状态`, or `流程阶段`.
-- Do not create platform workflow system fields such as `当前流程状态`, `当前处理人`, `当前处理节点`, or `流程标题`.
-- If `app_flow_apply` returns `FLOW_DEPENDENCY_MISSING`, fix schema with the returned `suggested_next_call`, read fields back, then retry the flow. Do not skip the workflow silently.
-
-Optional:
-
-- workflow, reminders, buttons, associated resources, sample data, roles, and permissions when the user asks for them or the business process clearly depends on them
-
-## Standard Path
-
-1. Resolve or create package: `package_get` / `package_apply`.
-2. Draft all apps and relations with stable `client_key` values.
-3. Run one multi-app `app_schema_apply` with `apps[]`.
-4. If write result is uncertain, run readback before retrying.
-5. For each app, apply layout.
-6. Apply workflow with `app_flow_apply` when the user asks for approval, fill, copy, reminders, or process routing.
-7. Apply views; declare ordinary business buttons in `action_buttons` while designing the core operating views.
-8. Create charts before portals when the portal needs metrics or BI sections. Keep chart payloads business-scoped, commonly 4-8 upserts by app or topic. Larger calls are accepted; if `CHART_UPSERT_BATCH_SIZE_RECOMMENDED` appears, read back before retrying and only repair failed items.
-9. Add associated resources and advanced standalone buttons when they are part of the requested business process.
-10. Create portal only after referenced apps, views, and charts are known.
-11. Before the final response, write the complete-system delivery summary file described below.
-
-## Field Modeling Rules
-
-- Use agent-friendly field types in drafts: `text`, `multiline`, `select`, `multi_select`, `number`, `amount`, `date`, `datetime`, `member`, `department`, `attachment`, `relation`. The tool normalizes aliases such as `multiline -> long_text` and `select -> single_select`.
-- Readback may show canonical field types such as `long_text` or `single_select`; do not rewrite fields just because aliases were normalized.
-- Create only business fields. Do not create platform system fields listed in Required; reference them only where a tool explicitly supports system fields, such as button `source_field: "数据ID"`.
-- Use `number` for ratios, completion rates, scores, percentages, durations, and quantities that may need decimals. Use `amount` only for currency/money semantics. This prevents sample data from producing decimal values for a field that the backend treats as integer money.
-- For select fields, define the option set during schema design. Later sample data must use only those option labels or ids.
-- Relation fields must include `target_app_ref` for same-batch apps or `target_app_key` for existing apps, plus `display_field: {"name": "..."}` and `visible_fields: [{"name": "..."}]`; do not write bare strings for display/visible field selectors.
-- Do not impose a one-relation-field-per-app limit. Model the real business links and let backend validation/readback decide whether a specific relation is unsupported.
-
-## View Query Rules
-
-- Use `filters` for fixed saved filters that apply when the view opens.
-- Use `query_conditions` only for the frontend query panel layout. It is not another filter DSL and it does not express OR.
-- `query_conditions.rows` should contain query-panel fields such as text, long text, number, amount, date/datetime, select, member, department, phone, email, or boolean.
-- Do not put relation, attachment, subtable/subfield, address, Q-Linker, or code-block fields in `query_conditions`.
-- For current-record related views/reports, use `app_associated_resources_apply.match_mappings`, not `query_conditions`.
-
-## Chart Rules
-
-- Read `app_get_fields.chart_fields` before chart apply; normal form fields are not enough for QingBI dimensions, metrics, or filters.
-- Use semantic chart input first: `metric`, `metrics`, `group_by`, and `where`.
-- One KPI card uses `target` / `indicator` with `metric: "count(*)"` or `metric: "sum(金额)"`.
-- Grouped distribution uses `bar` / `columnar` / `pie` with `group_by + metric`.
-- Trend uses `line` / `area` / `columnar` with a date/month `group_by`.
-- Two-metric comparison uses `dualaxes` with `left_metric` and `right_metric`.
-- Do not use `summary` for a single KPI; `summary` is for table-style grouped summaries.
-- Do not handwrite raw `indicator_field_ids`, `selectedMetrics`, or QingBI filter matrices on the main path.
-- For complete systems, keep new chart writes business-scoped, commonly 4-8 charts by app or topic; larger calls are accepted but should be read back before retrying.
-
-## Button Rules
-
-- Design ordinary business buttons with the view: `app_views_apply.upsert_views[].action_buttons` or `patch_views[].set.action_buttons`.
-- Use `app_custom_buttons_apply` only for style/icon changes, cross-view reuse, deleting button bodies, bulk binding reorder, or exact qRobot/wings configs.
-- Use `add_data` when a current record creates a downstream/child record, such as order -> acceptance, work order -> inspection, or customer -> follow-up. Configure `target_app_key + field_mappings`; map `source_field: "数据ID"` to the target relation/reference field when linking back to the source record.
-- Use `link` only for SOP, help, external system, or fixed URL navigation. Do not use `link` to fake approval, status transition, or data writeback.
-- Use `qRobot`/`wings` only when the user provides exact existing automation config. Do not invent ids, parameters, or hidden automation.
-- Prefer `detail` for current-record add-data actions, `list` for row actions, and `header` for global actions with no current-row context. Do not use current-record `field_mappings` on `header`.
-- Approval, rejection, close-task, and status transition should be modeled as workflow/task behavior or existing automation; they are not generic custom-button types.
-- Do not claim a complete operational system if all core operating views have no buttons and no reason is given.
-
-## Delivery Summary File
-
-For complete-system builds, create or update one local JSON file before the final response:
-
-`tmp/qingflow_system_build_summary.json`
-
-Use this file as the structured source of truth for the final report. Include at least:
-
-```json
-{
-  "package_id": 0,
-  "package_name": "",
-  "portal_dash_key": "",
-  "portal_live_status": "verified | unverified | not_created",
-  "front_end_visible": true,
-  "apps": [
-    {
-      "app_key": "",
-      "app_name": "",
-      "fields_count": 0,
-      "views_count": 0,
-      "flows_count": 0,
-      "charts_count": 0,
-      "publish_verify_status": "verified | unverified | failed"
-    }
-  ],
-  "warnings": [],
-  "partial_items": [],
-  "needs_followup": []
-}
-```
-
-Rules:
-
-- Populate IDs and counts from readback, not from intended payload only.
-- If a required resource is not verified, put it in `partial_items` or `needs_followup` instead of reporting the system as fully complete.
-- If the user later adds a data-entry task, keep that separate from the system-build summary unless the user explicitly wants one combined report.
-- The final response should match this file: completed resources, unverified items, frontend visibility, and follow-up needs must not contradict the JSON.
-- `front_end_visible=true` only when the relevant portal/app publish or live readback proves it. Backend write success alone is not enough.
-- Do not mark workflow as missing when the user did not ask for approval, fill, copy, reminders, or process routing. Report it as "not requested/not configured".
-- If `partial_items` or `needs_followup` is non-empty, the final status is partial, not complete.
-- When running from the CLI repo or a test harness, validate the file with:
-  `python scripts/validate_system_build_summary.py tmp/qingflow_system_build_summary.json`.
-
-Final response shape:
-
-```text
-已完成：...
-未验证/待确认：...
-前端可见：是/否/未确认
-需要继续修复：是/否；原因...
-```
-
-## Recovery Rules
-
-- Timeout, `partial_success`, `write_executed=true`, `safe_to_retry=false`, or incomplete readback means `write_may_have_succeeded`.
-- Next action is always `readback_before_retry`: read package, resolve intended apps, then read fields/relations.
-- Retry only verified missing apps, fields, or relations.
-- Do not rebuild the system as separate single-app creates.
-- Do not create `V2`, `测试`, timestamp, or random-suffix apps to bypass duplicate names.
-
-## Portal Template
-
-- Top area: one business entry grid plus one todo/common/frequent component when useful.
-- Metrics: one row of 4-6 indicator/target cards with portal section `role: "metric"`; recommended height 5.
-- BI charts: one row of 2-3 charts, 1-2 rows; recommended height 7.
-- Data views: one row of 1-2 concrete views, 1-2 rows; recommended height 11.
-- PC layout uses 24 columns. Components in the same row share the same `y`, must have the same `rows`, and their `cols` should sum to 24.
-- Business-entry grid components must include real `config.items[]` entries linking to apps or portals; never submit an empty grid container.
-- Build the portal only after referenced apps, raw `view_key`s, and chart ids/keys have been read back.
-- Standard section order is business entry -> metric cards -> BI charts -> concrete business views.
-- Do not reference platform default views such as `全部数据` / `我的数据` as main portal data views.
-- Do not use portal `source_type: "filter"` as the normal automation path; it is raw/unstable and not part of the unified filter DSL.
-
-## Stop Conditions
-
-- If the user only asked for one app, switch to the single-app guide.
-- If a same/similar package or app set already exists and the user did not say whether to extend, repair, replace, or create new, stop and ask. Do not start probing with new names.
-- If readback shows part of the requested system already exists, list existing apps/fields/views/charts/portal, identify gaps, and patch only the missing or incorrect slices.
-- If required package/app/field/relation readback contradicts the intended model, repair the specific missing slice before building dependent resources.
-- If a public tool cannot express a needed business feature, state the gap and ask before using any fallback or submitting feedback.

package/skills/qingflow-app-builder/references/single-app-development-guide.md

@@ -1,87 +0,0 @@
-# Single App Development Guide
-
-Use this when the user asks for one app/form, or gives one `app_key`.
-If the user asks for a package, system, or several related modules, use `complete-system-development-guide.md` instead.
-
-## Recommended Completeness
-
-Required:
-
-- target package/app resolved by `package_get`, `app_resolve`, or `app_get`
-- business fields created or updated through `app_schema_apply`
-- exactly one readable top-level `as_data_title: true`
-- no platform system fields in `add_fields`
-- layout places the important fields
-- at least one business view beyond platform default views when the task includes user-facing list work
-
-Strongly recommended:
-
-- saved filters and query panel fields for the main operating views
-- 1-3 concrete business buttons on core operating views through `app_views_apply.action_buttons`, when the view has real actions
-- simple charts when the app has status, amount, date, or owner fields worth tracking
-- associated resources or advanced standalone buttons only when they support a concrete workflow
-
-Optional:
-
-- workflow, portal entry, sample data, roles, or visibility changes when requested by the user or clearly needed by the app's job
-
-Workflow preflight:
-
-- If the app will have approval/fill/copy workflow nodes, add one explicit business status `select` field first, such as `状态`, `处理状态`, `审批状态`, `工单状态`, or `流程阶段`.
-- Do not create platform workflow system fields: `当前流程状态`, `当前处理人`, `当前处理节点`, or `流程标题`.
-
-## Standard Path
-
-1. Read current target: `app_resolve` or `app_get`.
-2. Read current fields: `app_get_fields`.
-3. Apply fields with `app_schema_apply`.
-4. Apply layout with `app_layout_apply`.
-5. Apply workflow with `app_flow_apply` when the user asks for approval, fill, copy, reminders, or process routing.
-6. Apply views with `app_views_apply` when list/table/card/gantt behavior is part of the request; declare ordinary business buttons in `action_buttons` while designing the view.
-7. Apply charts/associated resources/advanced standalone buttons only if they are part of the app's actual workflow.
-8. Use `app_publish_verify` only when explicit live verification is required.
-
-## Field Rules
-
-- Use agent-friendly field types where possible: `text`, `multiline`, `select`, `multi_select`, `number`, `amount`, `date`, `datetime`, `member`, `department`, `attachment`, `relation`.
-- The tool normalizes aliases: `multiline -> long_text`, `select -> single_select`, `checkbox -> multi_select`. Readback may show canonical types; do not treat that as a failed write.
-- Select fields must define `options` during schema design. Options may be strings or objects such as `{"label": "进行中"}`; later sample data should use those option labels or ids.
-- Relation fields are for real cross-object links. If used, include `target_app_key` for an existing app or `target_app_ref` for a same-batch app, plus `display_field: {"name": "..."}` and `visible_fields: [{"name": "..."}]`.
-- Do not impose a one-relation-field limit. Add the relation fields the business needs, then rely on backend validation and readback.
-- Do not create `数据ID`, `编号`, `申请人`, `申请时间`, `创建人`, `创建时间`, `提交人`, `提交时间`, `更新时间`, `更新人`, `当前流程状态`, `当前处理人`, `当前处理节点`, or `流程标题`.
-- Do not create built-in default views such as `全部数据` or `我的数据`; Qingflow provides system views.
-
-## View Query Rules
-
-- `filters` are fixed saved filters; `query_conditions` only configures frontend query-panel fields.
-- Put only query-panel fields in `query_conditions.rows`: text, long text, number, amount, date/datetime, select, member, department, phone, email, or boolean.
-- Do not put relation, attachment, subtable/subfield, address, Q-Linker, or code-block fields in `query_conditions`; use fixed `filters` or associated-resource `match_mappings` instead.
-
-## Chart Rules
-
-- Read `app_get_fields.chart_fields` before chart apply; normal form fields are not enough for QingBI dimensions, metrics, or filters.
-- Use semantic chart input first: `metric`, `metrics`, `group_by`, and `where`.
-- One KPI card uses `target` / `indicator` with `metric: "count(*)"` or `metric: "sum(金额)"`.
-- Grouped distribution uses `bar` / `columnar` / `pie` with `group_by + metric`.
-- Trend uses `line` / `area` / `columnar` with a date/month `group_by`.
-- Do not use `summary` for a single KPI; `summary` is for table-style grouped summaries.
-- Do not handwrite raw `indicator_field_ids`, `selectedMetrics`, or QingBI filter matrices on the main path.
-
-## Button Rules
-
-- Use `action_buttons` for ordinary buttons tied to one view.
-- Use `app_custom_buttons_apply` only for style/icon changes, cross-view reuse, deleting button bodies, bulk binding reorder, or exact qRobot/wings configs.
-- Use `add_data` when a current record creates a downstream/child record; configure `target_app_key + field_mappings`, usually mapping `source_field: "数据ID"` to the target relation/reference field.
-- Use `link` only for SOP, help, external system, or fixed URL navigation. Do not use it to fake approval, status transition, or data writeback.
-- Use `qRobot`/`wings` only when the user provides exact existing automation config.
-- Prefer `detail` for current-record add-data actions, `list` for row actions, and `header` for global actions with no current-row context. Do not use current-record `field_mappings` on `header`.
-- Approval, rejection, close-task, and status transition should be workflow/task behavior or existing automation; they are not generic custom-button types.
-
-## Stop Conditions
-
-- If the task actually needs multiple business objects, stop and switch to the complete-system guide.
-- If an existing app with the same or very similar name appears and the user did not explicitly say update, extend, or create new, stop and ask which target to use.
-- If readback shows the requested app already has some resources, patch the verified gaps instead of recreating the app.
-- If a write returns `partial_success`, `write_executed=true`, or `safe_to_retry=false`, read back before retrying.
-- If the same validation error repeats twice, re-read `builder_tool_contract` instead of guessing.
-- Do not create `V2`, `测试`, timestamp, or random-suffix apps to bypass duplicate names in a real business package.

package/skills/qingflow-app-builder/scripts/validate_system_build_summary.py

@@ -1,124 +0,0 @@
-#!/usr/bin/env python3
-from __future__ import annotations
-
-import argparse
-import json
-import sys
-from pathlib import Path
-from typing import Any
-
-
-VALID_PORTAL_STATUSES = {"verified", "unverified", "not_created"}
-VALID_APP_VERIFY_STATUSES = {"verified", "unverified", "failed"}
-
-
-def main(argv: list[str] | None = None) -> int:
-    parser = argparse.ArgumentParser(description="Validate a Qingflow complete-system delivery summary JSON file.")
-    parser.add_argument("summary_file", nargs="?", default="tmp/qingflow_system_build_summary.json")
-    args = parser.parse_args(argv)
-    path = Path(args.summary_file)
-    issues = validate_summary_file(path)
-    if issues:
-        _emit({"status": "failed", "error_code": "SYSTEM_BUILD_SUMMARY_INVALID", "path": str(path), "issues": issues})
-        return 1
-    payload = json.loads(path.read_text(encoding="utf-8"))
-    _emit(
-        {
-            "status": "success",
-            "path": str(path),
-            "summary": {
-                "package_id": payload.get("package_id"),
-                "package_name": payload.get("package_name"),
-                "portal_dash_key": payload.get("portal_dash_key"),
-                "portal_live_status": payload.get("portal_live_status"),
-                "app_count": len(payload.get("apps") or []),
-                "partial_count": len(payload.get("partial_items") or []),
-                "needs_followup_count": len(payload.get("needs_followup") or []),
-            },
-        }
-    )
-    return 0
-
-
-def validate_summary_file(path: Path) -> list[dict[str, Any]]:
-    if not path.exists():
-        return [_issue("MISSING_FILE", "$", f"summary file does not exist: {path}")]
-    try:
-        payload = json.loads(path.read_text(encoding="utf-8"))
-    except OSError as exc:
-        return [_issue("READ_FAILED", "$", str(exc))]
-    except json.JSONDecodeError as exc:
-        return [_issue("INVALID_JSON", "$", exc.msg)]
-    if not isinstance(payload, dict):
-        return [_issue("INVALID_ROOT", "$", "summary root must be a JSON object")]
-
-    issues: list[dict[str, Any]] = []
-    _require_positive_int(payload, "package_id", issues)
-    _require_nonempty_string(payload, "package_name", issues)
-    _require_bool(payload, "front_end_visible", issues)
-    _require_string_enum(payload, "portal_live_status", VALID_PORTAL_STATUSES, issues)
-    if payload.get("portal_live_status") == "verified":
-        _require_nonempty_string(payload, "portal_dash_key", issues)
-    elif "portal_dash_key" in payload and payload.get("portal_dash_key") is not None and not isinstance(payload.get("portal_dash_key"), str):
-        issues.append(_issue("INVALID_TYPE", "$.portal_dash_key", "portal_dash_key must be a string when present"))
-
-    apps = payload.get("apps")
-    if not isinstance(apps, list) or not apps:
-        issues.append(_issue("INVALID_APPS", "$.apps", "apps must be a non-empty array"))
-    else:
-        for index, app in enumerate(apps):
-            prefix = f"$.apps[{index}]"
-            if not isinstance(app, dict):
-                issues.append(_issue("INVALID_APP_ITEM", prefix, "app item must be an object"))
-                continue
-            _require_nonempty_string(app, "app_key", issues, prefix)
-            _require_nonempty_string(app, "app_name", issues, prefix)
-            for key in ("fields_count", "views_count", "flows_count", "charts_count"):
-                _require_nonnegative_int(app, key, issues, prefix)
-            _require_string_enum(app, "publish_verify_status", VALID_APP_VERIFY_STATUSES, issues, prefix)
-
-    for key in ("warnings", "partial_items", "needs_followup"):
-        if not isinstance(payload.get(key), list):
-            issues.append(_issue("INVALID_TYPE", f"$.{key}", f"{key} must be an array"))
-    return issues
-
-
-def _require_positive_int(payload: dict[str, Any], key: str, issues: list[dict[str, Any]], prefix: str = "$") -> None:
-    value = payload.get(key)
-    if isinstance(value, bool) or not isinstance(value, int) or value <= 0:
-        issues.append(_issue("INVALID_TYPE", f"{prefix}.{key}", f"{key} must be a positive integer"))
-
-
-def _require_nonnegative_int(payload: dict[str, Any], key: str, issues: list[dict[str, Any]], prefix: str = "$") -> None:
-    value = payload.get(key)
-    if isinstance(value, bool) or not isinstance(value, int) or value < 0:
-        issues.append(_issue("INVALID_TYPE", f"{prefix}.{key}", f"{key} must be a non-negative integer"))
-
-
-def _require_nonempty_string(payload: dict[str, Any], key: str, issues: list[dict[str, Any]], prefix: str = "$") -> None:
-    value = payload.get(key)
-    if not isinstance(value, str) or not value.strip():
-        issues.append(_issue("INVALID_TYPE", f"{prefix}.{key}", f"{key} must be a non-empty string"))
-
-
-def _require_bool(payload: dict[str, Any], key: str, issues: list[dict[str, Any]], prefix: str = "$") -> None:
-    if not isinstance(payload.get(key), bool):
-        issues.append(_issue("INVALID_TYPE", f"{prefix}.{key}", f"{key} must be a boolean"))
-
-
-def _require_string_enum(payload: dict[str, Any], key: str, allowed: set[str], issues: list[dict[str, Any]], prefix: str = "$") -> None:
-    value = payload.get(key)
-    if value not in allowed:
-        issues.append(_issue("INVALID_VALUE", f"{prefix}.{key}", f"{key} must be one of {sorted(allowed)}"))
-
-
-def _issue(code: str, path: str, message: str) -> dict[str, Any]:
-    return {"code": code, "path": path, "message": message}
-
-
-def _emit(payload: dict[str, Any]) -> None:
-    print(json.dumps(payload, ensure_ascii=False, indent=2))
-
-
-if __name__ == "__main__":
-    sys.exit(main())

package/src/qingflow_mcp/solution/compiler/workflow_compiler.py

@@ -1,173 +0,0 @@
-from __future__ import annotations
-
-from typing import Any
-
-from ..spec_models import EntitySpec, WorkflowNodeType
-
-
-WORKFLOW_TYPE_MAP = {
-    WorkflowNodeType.start: {"type": 0, "dealType": 3},
-    WorkflowNodeType.branch: {"type": 1, "dealType": None},
-    WorkflowNodeType.audit: {"type": 0, "dealType": 0},
-    WorkflowNodeType.fill: {"type": 0, "dealType": 1},
-    WorkflowNodeType.copy: {"type": 0, "dealType": 2},
-    WorkflowNodeType.webhook: {"type": 3, "dealType": 10},
-    WorkflowNodeType.condition: {"type": 2, "dealType": None},
-}
-
-
-def _default_audit_user_infos() -> dict[str, Any]:
-    return {
-        "member": [],
-        "depart": [],
-        "role": [],
-        "dynamic": [],
-        "includeSubDeparts": None,
-        "externalMemberList": [],
-        "externalDepartList": [],
-        "role_refs": [],
-    }
-
-
-def compile_workflow(entity: EntitySpec) -> dict[str, Any] | None:
-    workflow = entity.workflow
-    if workflow is None or not workflow.enabled:
-        return None
-    actions: list[dict[str, Any]] = []
-    seen_node_ids: set[str] = set()
-    created_extra_branch_lanes: set[str] = set()
-    start_node_ids = {
-        node.node_id
-        for node in workflow.nodes
-        if node.node_type == WorkflowNodeType.start
-    }
-    for node in workflow.nodes:
-        if node.node_type == WorkflowNodeType.start:
-            seen_node_ids.add(node.node_id)
-            continue
-        if node.parent_node_id and node.parent_node_id not in seen_node_ids:
-            raise ValueError(f"workflow node '{node.node_id}' must appear after parent node '{node.parent_node_id}'")
-        if node.branch_parent_id and node.branch_parent_id not in seen_node_ids:
-            raise ValueError(f"workflow node '{node.node_id}' must appear after branch node '{node.branch_parent_id}'")
-        branch_index = _branch_index(node)
-        branch_lane_ref = _branch_lane_ref(node.branch_parent_id, branch_index) if node.branch_parent_id else None
-        if branch_lane_ref and branch_index > 2 and branch_lane_ref not in created_extra_branch_lanes:
-            actions.append(
-                {
-                    "action": "create_sub_branch",
-                    "node_id": branch_lane_ref,
-                    "payload": {
-                        "editVersionNo": 1,
-                        "auditNodeRef": node.branch_parent_id,
-                    },
-                }
-            )
-            created_extra_branch_lanes.add(branch_lane_ref)
-        lane_only = bool((node.config or {}).get("__lane_only__")) and node.node_type == WorkflowNodeType.condition and branch_lane_ref
-        if lane_only:
-            lane_payload = {key: value for key, value in node.config.items() if key != "__lane_only__"}
-            actions.append(
-                {
-                    "action": "update_node",
-                    "node_id": branch_lane_ref,
-                    "node_name": node.name,
-                    "node_type": node.node_type.value,
-                    "payload": {
-                        "editVersionNo": 1,
-                        "auditNodeName": node.name,
-                        "type": WORKFLOW_TYPE_MAP[node.node_type]["type"],
-                        "dealType": WORKFLOW_TYPE_MAP[node.node_type]["dealType"],
-                        **lane_payload,
-                    },
-                }
-            )
-            seen_node_ids.add(node.node_id)
-            continue
-        actions.append(
-            {
-                "action": "add_node",
-                "node_id": node.node_id,
-                "node_name": node.name,
-                "node_type": node.node_type.value,
-                "payload": {
-                    "editVersionNo": 1,
-                    "auditNodeName": node.name,
-                    "type": WORKFLOW_TYPE_MAP[node.node_type]["type"],
-                    "dealType": WORKFLOW_TYPE_MAP[node.node_type]["dealType"],
-                    "prevNodeRef": _prev_node_ref(node, branch_lane_ref, start_node_ids),
-                    "auditUserInfos": _build_audit_user_infos(node)
-                    if node.node_type in {WorkflowNodeType.audit, WorkflowNodeType.fill, WorkflowNodeType.copy}
-                    else None,
-                    **node.config,
-                },
-            }
-        )
-        seen_node_ids.add(node.node_id)
-    return {
-        "global_settings": {
-            "editVersionNo": 1,
-            **workflow.global_settings,
-        },
-        "actions": actions,
-    }
-
-
-def _build_audit_user_infos(node) -> dict[str, Any]:
-    audit_user_infos = _default_audit_user_infos()
-    assignees = node.assignees or {}
-    member_uids = assignees.get("member_uids") or []
-    if member_uids:
-        audit_user_infos["member"] = [
-            {"uid": uid, "beingFrontendConfig": True}
-            for uid in member_uids
-            if isinstance(uid, int) and uid > 0
-        ]
-    role_refs = assignees.get("role_refs") or []
-    if role_refs:
-        audit_user_infos["role_refs"] = [role_ref for role_ref in role_refs if role_ref]
-    role_entries = assignees.get("role_entries") or []
-    if role_entries:
-        audit_user_infos["role"] = [
-            {
-                "roleId": int(entry.get("roleId") or entry.get("role_id")),
-                "roleName": entry.get("roleName") or entry.get("role_name") or str(entry.get("roleId") or entry.get("role_id")),
-                "roleIcon": entry.get("roleIcon") or entry.get("role_icon") or "ex-user-outlined",
-                "beingFrontendConfig": True,
-            }
-            for entry in role_entries
-            if isinstance(entry, dict) and isinstance(entry.get("roleId") or entry.get("role_id"), int) and int(entry.get("roleId") or entry.get("role_id")) > 0
-        ]
-    include_sub_departs = assignees.get("include_sub_departs")
-    if include_sub_departs is not None:
-        audit_user_infos["includeSubDeparts"] = bool(include_sub_departs)
-    return audit_user_infos
-
-
-def _prev_node_ref(node, branch_lane_ref: str | None, start_node_ids: set[str]) -> str:
-    if branch_lane_ref:
-        if node.parent_node_id and node.parent_node_id != node.branch_parent_id:
-            return node.parent_node_id
-        return branch_lane_ref
-    if node.parent_node_id in start_node_ids:
-        return "__applicant__"
-    return node.parent_node_id or "__applicant__"
-
-
-def _branch_index(node) -> int:
-    config = node.config or {}
-    raw_value = getattr(node, "branch_index", None)
-    if raw_value is None:
-        raw_value = config.get("branch_index", config.get("branchIndex", config.get("lane_index", config.get("laneIndex", 1))))
-    try:
-        branch_index = int(raw_value)
-    except (TypeError, ValueError) as exc:
-        raise ValueError(f"workflow node '{node.node_id}' has invalid branch index '{raw_value}'") from exc
-    if branch_index <= 0:
-        raise ValueError(f"workflow node '{node.node_id}' branch index must be positive")
-    return branch_index
-
-
-def _branch_lane_ref(branch_parent_id: str | None, branch_index: int) -> str:
-    if not branch_parent_id:
-        raise ValueError("branch_parent_id is required for branch lane references")
-    return f"__branch_lane__{branch_parent_id}__{branch_index}"