# HyperTwist Phase 4 recognition-assisted launch priming packet

Created on `2026-05-06`

Status:

- first-party HyperTwist packet
- bounded Phase `4` orchestration / recognition follow-on slice

## Purpose

This packet advances the first recognition-aware runtime consumer above the already-landed recognition handoff and dashboard inspection slices.

The open task is:

- make recognition-assisted run launch behave like a real recognition lane instead of a passive delivery-mode label

It is not:

- a broad recognition UI pass
- a transport/protocol rewrite
- a speech or simulation packet
- a general dashboard redesign

## Scope

Bounded lane:

- prime the owned recognition session automatically when a recognition-assisted run is started
- make the dashboard transition surface reflect whether a recognition-assisted run is actually ready to begin
- reuse the existing recognition runtime/session APIs instead of introducing a second orchestration path

Out of scope:

- new provider capabilities
- frame-streaming changes
- coach-brief heuristics changes
- broad replay visualization work

## Why this was the right next packet

Before this slice:

- HyperTwist could derive recognition-biased coach guidance
- HyperTwist could start recognition-assisted runs
- HyperTwist could inspect live provider/session/replay-handoff state in the dashboard

But recognition-assisted launch still had a gap:

- the run start path did not proactively prime the owned recognition session
- the dashboard transition lane did not distinguish a recognition-assisted run that was ready from one blocked on sidecar readiness

So the next honest move was:

- tighten the orchestration seam between recognition-assisted run launch and the owned recognition runtime session

## What landed

Primary code changes:

- `UnrealHyperTwist/Source/UnrealHyperTwist/Private/HyperTwistTraining/HyperTwistTrainingSubsystem.cpp`
  - recognition-assisted `StartTrainingRunFromDeck(...)` now attempts to open the owned recognition session immediately after the active run is created
- `UnrealHyperTwist/Source/UnrealHyperTwist/Private/HyperTwistTraining/HyperTwistCoachDashboardWidget.cpp`
  - the dashboard current-run transition logic now distinguishes:
    - recognition-assisted runs whose recognition session is already open
    - recognition-assisted runs that can prime the session on continue
    - recognition-assisted runs blocked by sidecar readiness failure
  - the continue action now primes the recognition session before starting the attempt timer when the active run is recognition-assisted

## Product effect

Recognition-assisted launch is now more coherent:

- starting a recognition-assisted run no longer leaves recognition session setup purely implicit
- dashboard transition messaging now tells the user whether recognition is ready, will be primed on continue, or is blocked
- the same dashboard continue action can now recover the recognition session and start the attempt in one bounded lane when the sidecar is available

## Acceptance criteria

- recognition-assisted run launch now attempts to prime the owned recognition session
- dashboard transition copy reflects recognition launch readiness
- continuing a recognition-assisted run primes the recognition session before starting the attempt
- the packet stays within the existing subsystem/runtime/panel/dashboard surfaces
- full product build succeeds

## Validation checklist

1. build `UnrealHyperTwist.sln` / `UnrealHyperTwistEditor`
2. confirm ordinary timer/virtual-cube current-run continuation still works
3. confirm generated-mode continuation routing is unchanged
4. confirm recognition-assisted runs now surface clearer launch readiness in the dashboard

That is the packet.
