pipeline-model-interpreter

Pipeline model interpretation

Applicable scenarios

• The user directly posts a BK-CI pipeline or creative flow Model JSON
• The user asks "What does this pipeline do", "What does this orchestration mean", or "Help me understand this Stage/Job/plugin"
• The user wants an explanation of startup parameters, matrices, Finally, approvals, script plugins, and store plugin inputs/outputs
• The user provides atomCode、elementId、stepId、jobId and other information, and requests an explanation of its meaning in the orchestration

Not applicable scenarios

• Modifying model code, adding fields, or making compatibility changes
• Troubleshooting build runtime failure logs or execution status
• Designing fixed summary template output
• Need to understand YAML conversion, persistence, or version compatibility implementation details

Quick guidance

1. First restore the JSON into the Model -> Stage -> Container -> Element four-layer structure.
2. The first Stage in the TriggerContainer.params is preferentially interpreted as the startup parameter entry; the trigger plugin itself usually does not need to be expanded as a business step.
3. First determine the container type:trigger、vmBuild、normal, then determine the plugin type:linuxScript、windowsScript、marketBuild、marketBuildLess、subPipelineCall、manualReviewUserTask etc.
4. When explaining a plugin, also look at @type、atomCode、name、data.input、data.output and additionalOptions。
5. If the user asks about the overall meaning, first explain the main flow, key Stages/Jobs, startup parameter entry, and possible outputs; if only asking about a certain node, explain only the relevant slice.
6. When encountering an unknown atomCode , do not speculate about functionality; clearly mark "needs to be confirmed with plugin documentation" and list the key input/output fields.
7. When explaining the execution timing of a node, combine runCondition to judge; Element / Job / Stage each has independent enums at the three layers, do not mix them up.
8. For detailed analysis steps, common plugin quick reference, and parameter type quick reference, see reference/。

High-signal rules

• Creative flows and pipelines use the same model structure, and this skill applies to both
• containerHashId、jobId、element.id、stepId have different semantics and cannot be mixed
• status、startEpoch、elapsed、executeCount、timeCost and other runtime fields are ignored by default unless the user explicitly asks about runtime status
• additionalOptions.enable=false、jobControlOption.enable=false、stageControlOption.enable=false must be clearly marked as disabled
• Sensitive parameters or PASSWORD types are only marked as sensitive, and default values are not echoed

Key pitfalls

• Treating trigger plugins in TriggerContainer as the main business flow
• Treating runtime fields as orchestration semantics when explaining
• Ignoring child Jobs after matrix expansion, Finally Stage, approval control, and mutex groups
• Only looking at atomCode without looking at data.input / data.output, causing distorted plugin understanding
• Directly guessing the functionality of unknown store plugins instead of conservatively explaining the boundaries

Further reading

• Detailed analysis steps:reference/1-json-analysis-playbook.md
• Container, plugin, and parameter type quick reference:reference/2-common-plugin-and-container-hints.md
• classType / dispatchType / enum literal list:reference/3-classtype-and-enum-catalog.md
• If the user does not have the Model JSON and wants to retrieve it first, they can use managing-devops-pipeline or the orchestration query tool of the build Agent (get pipeline orchestration summary/get pipeline orchestration)
• If you need to understand the model code structure, version compatibility, or YAML conversion:pipeline-model-architecture