How to Choose

This page answers one question only:

• where should this capability actually live

Start with the shortest version

If you want to:

• explicitly invoke a named capability, use an action
• progressively transform a value, use pipeline
• block before the flow continues, use guard
• keep the main value unchanged and record or sync something, use effect
• get one final authoritative answer, use resolve
• own long-lived state, workers, or connections, use plugin lifecycle

Common questions

"I want to add default fields to the input"

Use pipeline.

"I want to stop the request immediately if permission is missing"

Use guard.

"I want to write one audit log every time this happens"

Use effect.

"I want to know the user's final role"

Use resolve.

"I want an external caller to trigger a named command"

Use an action.

"I want a long-lived cache, connection pool, or background worker"

Use plugin lifecycle.

Common bad splits

• using resolve for multi-plugin enrichment
• using effect as a hidden reliable job queue
• using guard while also rewriting values

One practical decomposition pattern

If one capability needs all of these:

• an explicit command entry
• runtime-chain extension
• long-lived state

then the clean split is often:

• action for explicit invocation
• pipeline / guard / effect / resolve for runtime-chain extension
• lifecycle for long-lived state

Related scenarios

• One full message flow
• Common bad vs good designs
• Plugin Runtime Composition