pipeline-template-module

Pipeline Template Module

Applicable Scenarios

Only modifying the structure of a single pipeline model, without involving template abstraction
Only a YAML conversion issue, without involving the template lifecycle
Only a store plugin or ordinary pipeline execution issue

First determine which main line you are dealing with:
- Template basic structure and version system: see reference/1-template-foundation.md
- Instantiation, batch operations, permissions: see reference/2-instance-version-permission.md
- PAC templates and store integration: see reference/3-pac-store-integration.md
- Troubleshooting, events, locks, and extensions: see reference/4-operations-extension.md
For template issues, first distinguish whether it is V1 or V2. For new feature decisions, complex version management, drafts, and PAC scenarios, usually prioritize V2.
The biggest difference between templates and ordinary pipelines is not that there is "one more model", but that there are more:
- Version semantics
- Instance association relationships
- Permission and sharing boundaries
- Possible store distribution and PAC sources
Whenever you change the template structure or template version logic, you must check at the same time:
- Template resource persistence
- Instantiation results
- Version compatibility
- The update impact on pipelines associated with the template
Do not mix PAC templates, store templates, and in-project templates into one mental model; their sources, permissions, and version flows are different.

The template module is responsible for "how to reuse and distribute pipeline definitions",pipeline-model-architecture is responsible for "what the model itself looks like"
Template versions and instance versions must be distinguished; do not equate the template version number with the pipeline runtime version
Batch instantiation, batch updates, and store installation will all amplify template design problems; before making changes, first assess the scope of impact on instances
PAC templates are affected by both the template system and the YAML conversion system

Not distinguishing V1 / V2 and directly changing template logic, resulting in changing the wrong chain
Only changing the template itself without looking at how pipelines that have already been instantiated are affected
Mistaking PAC template issues for ordinary template issues, or vice versa
Using the same set of permissions and version mindset for store templates, project templates, and public templates
For template changes, only verifying a single template without verifying batch instances, version switching, and historical compatibility