# HyperTwist Phase 4 gameplay generated-mode selector option interaction / dispatch 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 case-coverage surface by exposing one parameterized option interaction / dispatch surface for a chosen selector id.

The open tasks were:

- stop forcing gameplay / Blueprint callers to reconstruct runtime action-path rules just to decide whether choosing an imported option should launch a direct owned case or apply a generated-mode selector choice
- expose exact dispatch posture and dispatch arguments for each imported option
- keep the surface derived from already-cached gameplay consumer selector/runtime state plus the already-landed option-detail and case-coverage surfaces instead of widening into new backend behavior

It is not:

- a new selector-application behavior packet
- a generated-mode execution packet
- a launch-request refresh / execute-impact packet
- a broader gameplay UI composition pass

## Scope

Bounded lane:

- add first-party generated-mode selector option dispatch surfaces in shared training types
- add a coach-library helper that derives dispatch posture from the requested selector id plus the already-landed option-detail and case-coverage surfaces
- expose that parameterized dispatch surface on `HyperTwistTrainingPanelWidget` and `HyperTwistTrainingSessionActor`
- keep the derivation presentation-only and rooted in the already-owned runtime action paths

Out of scope:

- changing direct option-launch behavior
- changing generated-mode selector-choice apply behavior
- changing launch-request freshness rules
- widening into execute-impact posture yet

## 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 selector / application context
- those same consumers already exposed truthful selector roster / option-availability summary
- those same consumers already exposed truthful chosen-selector option detail
- those same consumers already exposed truthful chosen-selector option case coverage

But one thin consumer seam was still open:

- callers could tell whether an option still mapped to an owned case
- but they still had to know raw runtime branching rules to decide whether interacting with that option should launch a direct case, apply a generated-mode selector choice, or stay unavailable

That meant:

- case coverage was thin and reusable
- but actual option dispatch posture still leaked runtime action-path rules into callers

So the next bounded move was:

- keep the already-landed generated-mode context, roster, option-detail, and option-coverage surfaces unchanged
- and expose one narrow option interaction / dispatch surface above those already-cached surfaces

## What landed

Primary code changes:

- `UnrealHyperTwist/Source/UnrealHyperTwist/Public/HyperTwistTraining/HyperTwistTrainingTypes.h`
  - added `EHyperTwistTrainingCoachGeneratedModeOptionDispatchKind`
  - added `FHyperTwistTrainingCoachGeneratedModeSelectorOptionDispatchEntrySurface`
  - added `FHyperTwistTrainingCoachGeneratedModeSelectorOptionDispatchSurface`
- `UnrealHyperTwist/Source/UnrealHyperTwist/Public/HyperTwistTraining/HyperTwistTrainingCoachLibrary.h`
- `UnrealHyperTwist/Source/UnrealHyperTwist/Private/HyperTwistTraining/HyperTwistTrainingCoachLibrary.cpp`
  - added `DeriveCoachGeneratedModeSelectorOptionDispatchSurface(...)`
  - dispatch posture is derived from the requested selector id plus the already-landed option-detail and option-coverage surfaces
- `UnrealHyperTwist/Source/UnrealHyperTwist/Public/HyperTwistTraining/HyperTwistTrainingPanelWidget.h`
- `UnrealHyperTwist/Source/UnrealHyperTwist/Private/HyperTwistTraining/HyperTwistTrainingPanelWidget.cpp`
  - added `GetDisplayedCoachGeneratedModeSelectorOptionDispatchSurface(const FString& SelectorId)`
- `UnrealHyperTwist/Source/UnrealHyperTwist/Public/HyperTwistTraining/HyperTwistTrainingSessionActor.h`
- `UnrealHyperTwist/Source/UnrealHyperTwist/Private/HyperTwistTraining/HyperTwistTrainingSessionActor.cpp`
  - added `GetDisplayedCoachGeneratedModeSelectorOptionDispatchSurface(const FString& SelectorId)`

Surface behavior:

- reports whether each imported option dispatches as direct owned-case launch, generated-mode selector-choice apply, or unavailable
- exposes exact dispatch arguments for direct launch and generated-choice apply flows
- reports how the current cached selection would dispatch right now
- keeps the surface presentation-only and compatible with the already-landed generated-mode option-detail and case-coverage 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 execution-impact / launch-request-refresh surface so callers can render whether choosing an option would start an owned case immediately, leave generated-mode execute posture unchanged, or require launch-request refresh before execute without reading raw launch-request freshness or blocked-reason rules directly.
