Expose runtime generated-mode launch and selector context surfaces

This commit is contained in:
axiomlogicnexus 2026-05-09 04:51:12 +02:00
parent 95ef6de123
commit cbdf775721
4 changed files with 119 additions and 2 deletions

View file

@ -1163,6 +1163,63 @@ UHyperTwistTrainingRuntimeLibrary::GetActiveTrainingCoachVerificationRecognition
return FHyperTwistTrainingCoachVerificationRecognitionReviewContextSurface();
}
FHyperTwistTrainingCoachGeneratedModeLaunchExecutionContextSurface
UHyperTwistTrainingRuntimeLibrary::GetActiveTrainingCoachGeneratedModeLaunchExecutionContextSurface(
UObject* WorldContextObject
)
{
if (UHyperTwistTrainingSubsystem* TrainingSubsystem = GetTrainingSubsystem(WorldContextObject))
{
const FHyperTwistTrainingCoachPanelState PanelState =
TrainingSubsystem->GetActiveCoachPanelState();
const FHyperTwistTrainingCoachReadinessEligibilitySurface ReadinessEligibilitySurface =
GetActiveTrainingCoachReadinessEligibilitySurface(WorldContextObject);
const FHyperTwistTrainingCoachVerificationRecognitionReviewContextSurface
VerificationRecognitionReviewContextSurface =
GetActiveTrainingCoachVerificationRecognitionReviewContextSurface(
WorldContextObject
);
return UHyperTwistTrainingCoachLibrary::DeriveCoachGeneratedModeLaunchExecutionContextSurface(
PanelState,
ReadinessEligibilitySurface,
VerificationRecognitionReviewContextSurface
);
}
return FHyperTwistTrainingCoachGeneratedModeLaunchExecutionContextSurface();
}
FHyperTwistTrainingCoachGeneratedModeSelectorApplicationContextSurface
UHyperTwistTrainingRuntimeLibrary::GetActiveTrainingCoachGeneratedModeSelectorApplicationContextSurface(
UObject* WorldContextObject
)
{
if (UHyperTwistTrainingSubsystem* TrainingSubsystem = GetTrainingSubsystem(WorldContextObject))
{
const FHyperTwistTrainingRunState RunState = TrainingSubsystem->GetActiveRunState();
FHyperTwistTrainingImportedRuntimeSelectionState ImportedRuntimeSelectionState;
TrainingSubsystem->TryGetActiveImportedRuntimeSelectionState(ImportedRuntimeSelectionState);
FHyperTwistTrainingImportedGeneratedModeLaunchConfig LaunchConfig;
TrainingSubsystem->TryGetActiveImportedGeneratedModeLaunchConfig(LaunchConfig);
const FHyperTwistTrainingCoachGeneratedModeLaunchExecutionContextSurface
LaunchExecutionContextSurface =
GetActiveTrainingCoachGeneratedModeLaunchExecutionContextSurface(
WorldContextObject
);
return UHyperTwistTrainingCoachLibrary::DeriveCoachGeneratedModeSelectorApplicationContextSurface(
RunState.ActiveDeck,
ImportedRuntimeSelectionState,
LaunchConfig,
LaunchExecutionContextSurface
);
}
return FHyperTwistTrainingCoachGeneratedModeSelectorApplicationContextSurface();
}
TArray<FHyperTwistTrainingMethodSegment> UHyperTwistTrainingRuntimeLibrary::GetActiveTrainingLearnerMethodSegments(UObject* WorldContextObject)
{
if (UHyperTwistTrainingSubsystem* TrainingSubsystem = GetTrainingSubsystem(WorldContextObject))

View file

@ -309,6 +309,14 @@ public:
static FHyperTwistTrainingCoachVerificationRecognitionReviewContextSurface
GetActiveTrainingCoachVerificationRecognitionReviewContextSurface(UObject* WorldContextObject);
UFUNCTION(BlueprintPure, Category = "HyperTwist|Training|Coach", meta = (WorldContext = "WorldContextObject"))
static FHyperTwistTrainingCoachGeneratedModeLaunchExecutionContextSurface
GetActiveTrainingCoachGeneratedModeLaunchExecutionContextSurface(UObject* WorldContextObject);
UFUNCTION(BlueprintPure, Category = "HyperTwist|Training|Coach", meta = (WorldContext = "WorldContextObject"))
static FHyperTwistTrainingCoachGeneratedModeSelectorApplicationContextSurface
GetActiveTrainingCoachGeneratedModeSelectorApplicationContextSurface(UObject* WorldContextObject);
UFUNCTION(BlueprintPure, Category = "HyperTwist|Training", meta = (WorldContext = "WorldContextObject"))
static TArray<FHyperTwistTrainingMethodSegment> GetActiveTrainingLearnerMethodSegments(UObject* WorldContextObject);

View file

@ -68,8 +68,8 @@ Current correction call from the source-exposed audit and current execution refr
- the imported generated-mode gap is closed; request/config/selection plumbing and the bounded clean-room executor are already landed in first-party code
- the latest landed bounded `Phase 4` packet closes the retained-idle comparison/outcome actionability gap at the end of the recognition-assisted coach-to-review continuity lane, and the final retained-surface confirmation pass now leaves that closure lane functionally complete
- the retained idle widget surface now keeps retained comparison and decision history inspectable without continuing to advertise live launch or guidance-outcome actions once the coach-to-review loop has already collapsed to truthful closed-loop idle
- the latest landed bounded `Phase 4` packet stays on that same deliberate `UHyperTwistTrainingRuntimeLibrary` world-context consumer lane and adds active coach readiness/eligibility and verification/recognition/review-policy context surfaces over the already-landed active primary coach CTA, queue-control, queue-recovery, handoff-continuation, focus/provenance, and workload/budget surfaces, so gameplay/Blueprint callers can explain what is actionable now, what is blocked, and what repository-verification, recognition-provider, and review-policy context applies without reading raw booleans, suppression strings, or status/detail lines directly
- the current next bounded packet should stay on that same runtime-library consumer lane only if a real world-context gameplay or Blueprint caller still needs one more thin derived coach/generated-mode display contract or displayed-action convenience helper over already-cached state; otherwise choose the next roadmap lane deliberately instead of extending runtime-consumer widening by drift
- the latest landed bounded `Phase 4` packet stays on that same deliberate `UHyperTwistTrainingRuntimeLibrary` world-context consumer lane and adds active generated-mode launch/execution context and generated-mode selector/application context surfaces over the already-cached active coach panel state, readiness/eligibility and verification/recognition/review-policy context surfaces, active run state, imported runtime selection state, and imported generated-mode launch-config posture, so gameplay/Blueprint callers can explain generated-mode request, execution, selector coverage, and stored-request refresh posture without reading raw request, selection, runtime-surface, or launch-config fields directly
- the current next bounded packet should stay on that same runtime-library consumer lane only if a real world-context gameplay or Blueprint caller still needs one more thin derived coach/generated-mode display contract or displayed-action convenience helper over already-cached state; inside that lane the next aligned pair is the runtime-library generated-mode selector roster and selector option-menu surfaces, otherwise choose the next roadmap lane deliberately instead of extending runtime-consumer widening by drift
- the current execution-discipline rule that broad refactor / monolith-splitting work should not interrupt the active bounded roadmap packet unless structure is actually blocking it
## Current execution-reality references

View file

@ -0,0 +1,52 @@
# HyperTwist Phase 4 runtime-library generated-mode launch/execution and selector/application context surface packet
- bounded Phase `4` runtime-consumer slice
- date: `2026-05-09`
## Intent
Stay on the deliberate `UHyperTwistTrainingRuntimeLibrary` world-context consumer lane and expose the next truthful generated-mode display contracts above the already-landed active coach readiness/eligibility and verification/recognition/review-policy context surfaces.
## Why this packet exists
The prior runtime-library packet let world-context callers explain what is actionable now, what is blocked, and what repository-verification, recognition-provider, and review-policy context applies.
But callers still had to inspect raw generated-mode request/execution panel fields, imported selector-choice state, runtime-surface identity, and launch-config posture if they needed to explain:
- the latest generated-mode request and execution posture
- whether execution is staged, blocked, or ready
- how much selector coverage is already cached
- whether execute will reuse or refresh the stored request
That kept the runtime-library world-context seam behind the already-landed panel-widget and session-actor generated-mode display-contract lane.
## What changed
- added `GetActiveTrainingCoachGeneratedModeLaunchExecutionContextSurface()`
- added `GetActiveTrainingCoachGeneratedModeSelectorApplicationContextSurface()`
- derived the launch/execution context surface from the active coach panel state plus the already-landed runtime-library readiness/eligibility and verification/recognition/review-policy context surfaces
- derived the selector/application context surface from the active run deck, active imported runtime selection state, active imported generated-mode launch config, and the runtime-library launch/execution context surface
- kept the runtime-library lane purely compositional over already-cached coach/generated-mode state without reopening backend derivation
## Files
- `C:\HyperTwist\UnrealHyperTwist\Source\UnrealHyperTwist\Public\HyperTwistTraining\HyperTwistTrainingRuntimeLibrary.h`
- `C:\HyperTwist\UnrealHyperTwist\Source\UnrealHyperTwist\Private\HyperTwistTraining\HyperTwistTrainingRuntimeLibrary.cpp`
- `C:\HyperTwist\docs\HYPERTWIST_ROADMAP_OVERHAUL_EXPANSION_GUIDE.md`
## Outcome
World-context gameplay and Blueprint callers can now ask the runtime library for:
- the truthful generated-mode launch request / execution posture
- the truthful selector application coverage / stored-request refresh posture
without reading raw request ids, blocked-reason fields, selector-choice arrays, runtime-surface ids, or launch-config fields directly.
## Validation
- full `Development Editor | Win64` MSBuild on `UnrealHyperTwist.sln`
## Next clean slice
Stay on this runtime-library consumer lane only if a real world-context caller still needs one more thin derived coach/generated-mode display contract or displayed-action convenience helper over already-cached state. The next aligned pair inside that lane would be the runtime-library generated-mode selector roster and selector option-menu surfaces, because those are the next truthful selector-display contracts above the newly-landed selector/application context surface.