Plugin Runtime Composition

One of the most important design questions is:

Should this logic live in plugin actions or hooks, or in lifecycle-owned plugin runtime?

Good thin-plugin cases

• explicit user-facing actions
• hook participation
• system prompt injection
• setup or usage protocols
• small runtime HTTP surfaces

Good lifecycle-owned runtime cases

• queue workers
• cron engines
• durable session pools
• long-lived connections
• in-memory runtime state that must be cleaned up on stop

A practical rule

If the thing must start, stop, recover, or be polled over time, it probably needs lifecycle-owned plugin runtime, not just one thin action.

Real built-in references

• chat: queue worker owned by the plugin instance
• task: cron engine owned by the plugin instance
• schedule: lifecycle-only infrastructure plugin
• shell: long-lived shell sessions owned by the plugin instance

Related docs

• Plugin Design Patterns
• Plugin Lifecycle
• Built-ins Overview