# HyperTwist Phase 4 gameplay generated-mode selector option execution-impact / launch-request-refresh surface packet

Created on `2026-05-08`

Status:

- first-party HyperTwist packet
- bounded Phase `4` gameplay-facing consumer slice

## Purpose

This packet closes the next thin gameplay-facing consumer seam above the panel-widget and session-actor generated-mode selector option interaction / dispatch surface by exposing one parameterized option execution-impact surface for a chosen selector id.

The open tasks were:

- stop forcing gameplay / Blueprint callers to reconstruct launch-request freshness and blocked-execute rules just to explain what choosing an imported option would do to generated-mode execute posture
- expose whether an option would start a direct owned case immediately, keep generated-mode execute posture unchanged, realign with the stored request, require a fresh launch request before execute, or still leave execute blocked
- keep the surface derived from already-cached gameplay consumer run, selector, and request state plus the already-landed launch-execution, option-detail, and option-dispatch surfaces instead of widening into backend logic

It is not:

- a new selector-dispatch packet
- a new launch-request creation packet
- a generated-mode backend behavior change
- a broader gameplay UI composition pass

## Scope

Bounded lane:

- add first-party generated-mode selector option execution-impact surfaces in shared training types
- add a coach-library helper that derives execution-impact posture from the cached run state plus the already-landed launch-execution, option-detail, and option-dispatch surfaces
- expose that parameterized execution-impact surface on `HyperTwistTrainingPanelWidget` and `HyperTwistTrainingSessionActor`
- keep the derivation presentation-only and rooted in the already-owned selector-choice / launch-request / execute rules

Out of scope:

- changing selector-choice apply behavior
- changing direct owned-case option-launch behavior
- changing generated-mode execute or launch-request persistence behavior
- widening into higher-level UI composition or dashboard-only work

## Why this was the right next packet

Before this slice:

- gameplay-facing panel/session consumers already exposed truthful generated-mode launch / execution context
- those same consumers already exposed truthful chosen-selector option detail
- those same consumers already exposed truthful chosen-selector option dispatch posture

But one thin consumer seam was still open:

- callers could tell how an option dispatches
- but they still had to know raw launch-request freshness and blocked-execute rules to explain what that option would do to generated-mode execute posture

That meant:

- dispatch posture was thin and reusable
- but execute-impact posture still leaked runtime freshness/blocking rules into callers

So the next bounded move was:

- keep the already-landed generated-mode execute context, option-detail, and option-dispatch surfaces unchanged
- and expose one narrow option execution-impact / launch-request-refresh surface above those already-cached surfaces

## What landed

Primary code changes:

- `UnrealHyperTwist/Source/UnrealHyperTwist/Public/HyperTwistTraining/HyperTwistTrainingTypes.h`
  - added `EHyperTwistTrainingCoachGeneratedModeOptionExecutionImpactKind`
  - added `FHyperTwistTrainingCoachGeneratedModeSelectorOptionExecutionImpactEntrySurface`
  - added `FHyperTwistTrainingCoachGeneratedModeSelectorOptionExecutionImpactSurface`
- `UnrealHyperTwist/Source/UnrealHyperTwist/Public/HyperTwistTraining/HyperTwistTrainingCoachLibrary.h`
- `UnrealHyperTwist/Source/UnrealHyperTwist/Private/HyperTwistTraining/HyperTwistTrainingCoachLibrary.cpp`
  - added `DeriveCoachGeneratedModeSelectorOptionExecutionImpactSurface(...)`
  - execution-impact posture is derived from the cached run state plus the already-landed launch-execution, option-detail, and option-dispatch surfaces
- `UnrealHyperTwist/Source/UnrealHyperTwist/Public/HyperTwistTraining/HyperTwistTrainingPanelWidget.h`
- `UnrealHyperTwist/Source/UnrealHyperTwist/Private/HyperTwistTraining/HyperTwistTrainingPanelWidget.cpp`
  - added `GetDisplayedCoachGeneratedModeSelectorOptionExecutionImpactSurface(const FString& SelectorId)`
- `UnrealHyperTwist/Source/UnrealHyperTwist/Public/HyperTwistTraining/HyperTwistTrainingSessionActor.h`
- `UnrealHyperTwist/Source/UnrealHyperTwist/Private/HyperTwistTraining/HyperTwistTrainingSessionActor.cpp`
  - added `GetDisplayedCoachGeneratedModeSelectorOptionExecutionImpactSurface(const FString& SelectorId)`

Surface behavior:

- reports whether each imported option starts a direct owned case immediately, realigns with the stored request, leaves current execute posture unchanged, requires launch-request refresh before execute, or still leaves execute blocked
- exposes blocked-reason preview for options that still leave generated-mode execute unresolved
- reports how the current cached selection would affect generated-mode execute right now
- keeps the surface presentation-only and compatible with the already-landed generated-mode launch / execution, option-detail, and option-dispatch surfaces

## Validation

Validation target:

- full `Development Editor|Win64` build of `C:\HyperTwist\UnrealHyperTwist\UnrealHyperTwist.sln`

Result:

- passed with `0` warnings and `0` errors

## Follow-on

The next bounded packet on this same gameplay-facing consumer lane should stay thin and expose one generated-mode selector option request-alignment / execute-preview surface so callers can render hypothetical selector summary, stored-request alignment, and unresolved-selector preview for a chosen option without diffing cached selector choices or launch-request payloads directly.
