Pipeline Create Is Promotion Today
Architecture roadmaps often describe a convenience command that drafts a pipeline from a landed oneoff. That is a useful future tool, but a course must teach the product that exists. Today the promotion act is explicit pipeline creation: the operator compares records, writes the common template and policy, validates the row, and creates it.
This manual judgment is not merely missing automation. The hard part is deciding which details are stable craft and which are coincidence. A future promote helper can prefill candidates and cite source records; it still should not mint a row without an operator approving the abstraction.
The created row starts at version one and becomes live through the provider. It should include a clear title and description, closed template, required stages, review default, and optional brain hint. Immediately queue a representative dry task or inspect the rendered brief before trusting the row.
Record which occurrences justified promotion. That provenance helps future editors understand why fields exist and whether later task drift warrants a new version, a split pipeline, or graduation.
Teach the Live Verb
Use the supported pipeline-create surface and show the resulting row. Do not document an aspirational promote command as if it were available; stale operational lessons are worse than missing convenience.
A future helper earns adoption when it preserves the same approval gate, references source records, and produces a draft row rather than an irreversible abstraction.