yaml-pipeline-transfer

YAML Pipeline Conversion

Applicable Scenarios

Import YAML as a pipeline model
Export a pipeline model as YAML
PAC (Pipeline as Code) integration and synchronization
YAML templates, Step/Job/Stage template references
Issues related to YAML syntax, expressions, comment preservation, and anchor handling

Only modifying the pipeline model structure, without involving YAML representation
Only code repository integration, permissions, database, or execution scheduling issues
Only the runtime logic of a certain plugin, rather than a YAML-to-model conversion issue

First determine which category the issue belongs to, then continue reading the corresponding reference document:
- Main conversion chain:reference/1-transfer-flow.md
- PAC and templates:reference/2-pac-template.md
- Expressions, aspects, debugging, and extension:reference/3-debug-extension.md
YAML conversion issues are usually not single-point issues; distinguish between:
- YAML text parsing
- YAML data model
- YAML to Model
- Model to YAML
- Template expansion and PAC preprocessing
Whenever you change a YAML field or structure, you must also consider:
- Model mapping
- Compatibility with old YAML
- Bidirectional consistency between import and export
- Whether template references and expressions are affected
PAC, templates, expressions, and aspects often overlap with one another; do not treat them as completely independent modules.
If the issue is "execution is incorrect after conversion," first confirm whether it is a YAML conversion layer issue or whether process-module-architecture 's execution chain is amplifying the issue.

yaml-pipeline-transfer is responsible for "how YAML is represented and converted,"pipeline-model-architecture is responsible for "what the model looks like"
TransferMapper Solves text-layer issues such as serialization, formatting, comments, and anchors
ModelTransfer Is more about the business conversion between YAML and Model business transformation
Templates, PAC, expressions, and aspects belong to the enhancement layer that jointly affects the result before and after conversion
When changing YAML-related capabilities, always aim for "bidirectional consistency" and "historical compatibility"

Only fixing yaml2Model, not fixing model2Yaml, resulting in asymmetric import and export
Only validating ordinary YAML, not validating templates, PAC, comment preservation, and anchor scenarios
Misjudging a model field issue as a YAML parsing issue, or vice versa
Ignoring the impact of aspects, expressions, and template preprocessing on the final result
After modifying conversion rules, failing to regress historical YAML and existing templates