Remove Request.Changes and -Changes request parameter (use Request.Intent + Request.Context only)

[blindzero]

Problem Statement

IdLE currently supports an optional request parameter/property named Changes (e.g., New-IdleRequest -Changes ...) which is intended to carry precomputed deltas.

In practice, Changes introduces ambiguity and duplicated semantics with the primary workflow input model:

• With the adoption of Request.Intent and Request.Context, Changes becomes a third top-level input concept that is easy to misunderstand (“is it input, delta, state, or audit info?”).
• The Changes operational mode is not fully documented and is not consistently implemented as a first-class execution mode across steps/providers.
• Changes increases the request surface area and complicates validation, security, and documentation.

To preserve consistency and reduce ambiguity, IdLE should have a single canonical request input model:

• Request.Intent (what to do)
• Request.Context (what is known; read-only)

Any delta-like instructions can be modeled explicitly within Request.Intent where needed, rather than as a separate top-level Changes block.

Proposed Solution

Remove Changes completely and immediately as a breaking change:

• Remove -Changes parameter from public request creation cmdlets (e.g., New-IdleRequest, New-IdleRequestObject).
• Remove the Changes property from the request/domain model (e.g., IdleLifecycleRequest).
• Remove Request.Changes.* as an allowed root for template/value path resolution (if currently supported).
• Remove Changes from plan request snapshots / plan export.
• Update all docs/examples/tests to no longer mention or use Changes.

No deprecation window is introduced: the feature is removed consistently and comprehensively.

Alternatives Considered

1. Keep Changes as an optional “advanced mode”

• Maintains ambiguity and doubles request semantics; increases long-term maintenance.

2. Deprecate first, remove later

• Adds transitional complexity and prolongs inconsistent behavior; not aligned with IdLE’s consistency-first approach for breaking changes.

Impact

• Breaking change for any host/workflow that currently supplies Changes.
• Template strings/conditions referencing Request.Changes.* will fail and must be updated.
• Plan exports will no longer contain a Changes block.

The benefit is a simpler, clearer request model and reduced maintenance surface.

Dependencies

• Recommended alignment with the request schema separation issue (Request.Intent / Request.Context).
• This issue can be implemented before or together with the schema split, but the end state must have no Changes.

Definition of Done (Step-0-Ready / Agent-Safe)

Design / Contracts

• Document that IdLE request inputs are limited to Request.Intent and Request.Context (no Changes).
• Document replacement guidance:
  • if callers used Changes as “delta”, model such instructions explicitly under Request.Intent (host responsibility).

Implementation

• Remove -Changes from New-IdleRequest and any related public API cmdlets.
• Remove Changes from the request/domain model.
• Remove any internal handling/serialization of Changes (including plan snapshot/export).
• Remove Request.Changes.* from template/value-path resolution allow-lists.
• Ensure validation fails fast if a request payload contains a Changes property.

Tests (Pester)

• Public API test: New-IdleRequest -Changes is no longer accepted (parameter no longer exists).
• Validation test: request payload containing Changes fails fast with a clear error.
• Template resolution test: Request.Changes.* is not allowed and produces a clear error.
• Snapshot/export test: plan request snapshot contains no Changes.

Docs / Examples

• Remove all documentation references to Changes.
• Update any examples that used Changes to use Request.Intent instead.
• Ensure docs and reference pages do not mention -Changes or Request.Changes.

Non-Goals (explicit)

• No deprecation phase or backward compatibility shims.
• No automatic migration from Changes to another field by the engine (host must update).