# HyperTwist - WORKBENCH_FEATURE_TARGETS.md

## Purpose

Translate mature workbench capability into clean HyperTwist cockpit targets
without turning HyperTwist into a generic IDE clone or a generic admin
dashboard.

This file exists because HyperTwist now clearly has an operator/workbench side
in addition to its puzzle/training runtime, and that value must be described
concretely enough that future implementation and repo evaluation do not
underweight it.

## Core adoption rule

Adopt capability families, not another product's identity.

That means:

- reuse serious workbench ergonomics where they materially help training,
  coaching, review, or diagnostics
- do not copy another product literally
- do not let workbench behavior demote the Unreal-native training runtime

## Visual divergence rule

HyperTwist should adopt workbench capability without adopting a pane-saturated
generic enterprise shell.

The target feeling is:

- focused
- work-first
- training-first
- replay-aware
- inspection-friendly

not:

- a generic boxed IDE
- a web admin dashboard with puzzle art attached

## Canonical workbench targets

### 1. Unified command and navigation layer

HyperTwist should have:

- one command palette
- one object jump/search surface
- recent-context and return-to-context behavior
- search across runs, decks, replays, coach cases, challenge sessions,
  content packs, and settings

### 2. Explorer, bookmarks, and scratch adjuncts

HyperTwist should support:

- deck/content explorers
- preview-open behavior for non-destructive inspection
- bookmark lists and mnemonic anchors
- scratch notes/queries/temporary evidence

### 3. Diff, review, and local recovery

HyperTwist should support:

- structured diff/review for training state where useful
- replay comparison
- local-history-style recovery for relevant operator surfaces
- labels before risky apply/import/publish operations

### 4. Run, session, and live diagnostics

HyperTwist should support:

- session management as first-class cockpit value
- service dashboards for recognition, speech, imports, and coaching helpers
- interactive diagnostics tied to one run/session context

### 5. Testing, coverage, and profiling

HyperTwist engineering surfaces should support:

- validation cockpit behavior
- saved test sessions per packet/subsystem
- coverage/profiling/memory surfaces for runtime hot paths

Important distinction:

- engineering memory profiling here concerns runtime resources
- product memory lanes are governed separately by the memory doctrine

### 6. Terminal, external tools, and bounded sidecars

HyperTwist should support:

- bounded tool launch
- context-aware sidecar/service inspection
- explicit remote/session governance rather than ad hoc shell escapes

### 7. Settings, extensions, and optional adjunct governance

HyperTwist should support:

- strong settings organization
- separation between user-local and project/shared preferences where relevant
- explicit extension/adjunct governance
- self-service enable/disable control for optional assistive features

Governing doctrines:

- `C:\HyperTwist\docs\ops\HYPERTWIST_OPTIONAL_ASSISTIVE_FEATURE_DEACTIVATION_AND_REMOVABILITY_DOCTRINE_2026-05-21.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_SKILLIZATION_AND_COMMAND_SURFACE_DOCTRINE_2026-05-21.md`

## Mapping into HyperTwist doctrine

These targets should shape:

- `PRD.md`
- `ARCHITECTURE.md`
- `ROADMAP.md`
- `FEATURE_REGISTRY.md`
- `CAPABILITY_CONSOLIDATION_DOCTRINE.md`
- `API.md`
- `DEVELOPMENT.md`

## Guardrail

The cockpit must remain subordinate to the actual product identity.

The target is:

- one training runtime
- one operator cockpit
- many bounded tools

not:

- an Unreal skin over a generic IDE
- a detached browser admin panel
- a pile of unrelated panes pretending to cooperate
