Clarify and formalize IdLE.Steps.Common as first-party built-in steps

[blindzero]

Problem Statement

IdLE.Steps.Common currently contains steps such as:

• EmitEvent
• AssertRequired / AssertCondition
• SetState
• StopPlan

While technically optional and loaded like any other step module, these steps are de-facto required for:

• guardrails (environment safety, blast radius protection)
• early validation and clear failure modes
• meaningful observability (events, plan transparency)
• robust, reviewable workflows

This creates ambiguity:

• Are these steps optional utilities or core building blocks?
• What is the expected default experience when importing IdLE?
• Should hosts always be required to explicitly load IdLE.Steps.Common?

Without a clear decision, contributors and users cannot reliably reason about:

• what a “minimal but safe” IdLE setup looks like
• whether workflows may assume these steps to exist

Proposed Solution

• Keep IdLE.Core strictly engine-only
• Treat IdLE.Steps.Common as first-party built-ins
• Load them by default via the IdLE meta-module
• Allow hosts to disable or override built-ins explicitly
• Clearly document this behavior and expectations

Goals

• Clearly define the status of IdLE.Steps.Common
• Preserve the headless, engine-only nature of IdLE.Core
• Improve developer experience without sacrificing modularity
• Avoid hidden assumptions in workflows

Non-Goals

• ❌ Moving steps into IdLE.Core
• ❌ Adding new engine logic
• ❌ Forcing hosts to use built-in steps
• ❌ Introducing product- or provider-specific behavior

Impact

• Does this affect existing workflows?
• Any backward compatibility concerns?

Additional Context

Questions to Decide

1. Should IdLE.Steps.Common be considered first-party built-in steps?
2. Should these steps be loaded automatically when importing IdLE?
3. Should an explicit opt-out mechanism exist (e.g. -DisableBuiltInSteps)?
4. Which steps form the minimal built-in set required for safe workflows?
5. Where should this decision be documented?

• Architecture doc
• README
• CONTRIBUTING / STYLEGUIDE

Definition of Done

• Decision recorded (Architecture doc or ADR)
• Clear definition of “Built-in Common Steps”
• Default load behavior documented
• Opt-out behavior defined (if applicable)
• README and Architecture docs updated
• Tests cover default vs. opt-out behavior