Skip to content

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

Merged
blindzero merged 4 commits into
mainfrom
issues/27-Clarify-and-formalize-IdLEStepsCommon-as-first-party-built-in-steps
Jan 1, 2026
Merged

#27 - Clarify and formalize IdLE.Steps.Common as first-party built-in steps#40
blindzero merged 4 commits into
mainfrom
issues/27-Clarify-and-formalize-IdLEStepsCommon-as-first-party-built-in-steps

Conversation

@blindzero
Copy link
Copy Markdown
Owner

Summary

This PR formalizes IdLE.Steps.Common as a first-party built-in step pack that is available by default when importing the IdLE meta module, while not exporting step commands globally.

Motivation / Problem

Users expect a “batteries included” experience when importing IdLE. At the same time, we want to keep the global session state clean and avoid polluting the command namespace with step handler functions.

The engine’s step discovery also must work reliably when built-in step packs are loaded as nested/hidden modules.

What changed

  • Built-in step discovery in the engine now supports resolving step handlers from a loaded module’s exports and stores module-qualified handler names (e.g. IdLE.Steps.Common\Invoke-IdleStepEmitEvent) to avoid requiring global exports.
  • Tests were updated to validate the intended behavior:
    • IdLE.Steps.Common is available to the engine after importing IdLE (nested/hidden module is OK).
    • Step commands are not available via global Get-Command.
    • The step registry resolves built-ins to module-qualified handler names.
  • Documentation (README) clarifies the contract:
    • Import-Module IdLE = batteries-included (Core + built-in steps)
    • Import-Module IdLE.Core = engine-only import
    • Built-in steps are not exported globally by default.

Why this approach

  • Keeps IdLE.Core step-agnostic and host-agnostic.
  • Provides predictable default behavior for workflows (“built-ins available in IdLE”).
  • Avoids global session pollution while still enabling reliable discovery/execution.

How to test

  • Invoke-Pester (local / CI):
    • tests/ModuleSurface.Tests.ps1 covers the intended module/step behavior.
  • Manual sanity: Import-Module ./src/IdLE/IdLE.psd1 and verify:
    • Get-Module -All IdLE.Steps.Common returns the module
    • Get-Command Invoke-IdleStepEmitEvent returns nothing (not global)
    • Engine can still execute plans using built-in steps

Breaking changes

None expected. The change makes built-in step resolution more robust and documents the supported behavior.

Closes #27

@chatgpt-codex-connector
Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

@blindzero blindzero self-assigned this Jan 1, 2026
@chatgpt-codex-connector
Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

@blindzero blindzero merged commit 4ffae91 into main Jan 1, 2026
4 checks passed
@blindzero blindzero deleted the issues/27-Clarify-and-formalize-IdLEStepsCommon-as-first-party-built-in-steps branch January 1, 2026 17:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

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

1 participant