Nick Sutterer

Hi @elShiaLabeouf, wow, you have lots of ideas, I like that! :green_heart: Regarding your specific requirement, my suggestion would be to enhance `Operation::Result`, which is the actual object exposing `#success`...

Oh BTW, one more thing! An `Output` is not a terminus (or "end" as we used to call it). An output defines which outgoing connection goes where, and that might...

Hey @elShiaLabeouf feel free to hit me up directly on https://trailblazer.zulipchat.com to discuss :point_up:

Doesn't patching work here? https://trailblazer.to/2.1/docs/activity.html#activity-dsl-options-patching This implements "chained IDs" the way @Quantenradierer need it.

So, do we agree we have a patching bug here, then? Regarding the `insert_id` points, we have the chance now to push something into the new `dsl` minor release. Let...

@Quantenradierer How would you use the insertion logic with an array? You mean you want to insert a bunch of sequential steps at a certain point at once?

> One of our requirements is that the engine must define a whole usable process. Maybe you're misunderstanding patching? It is possible and designed to insert/alter as many steps as...

Thanks - that clarifies it! You'd use patch as follows to add/alter the *nested* OP (pseudo code!!!). ```ruby class TestOperation < Trailblazer::Operation step Wrap(Transaction), patch: [:base_operation] -> { step added_step,...

Yo @Quantenradierer, moin! I am envisioning a more intuitive syntax for patching, how about this? ```ruby class TestOperation < Trailblazer::Operation patch: ["wrap/Transaction", :base_operation] -> { step added_step, after ... }]...

In DSL, we could use the `Start` event for modelling, only, and skip it when compiling the activity.