# HyperTwist Phase 0R Packet 0R-A Deep Source Evaluation

Created on `2026-05-12`

## Status

`Packet 0R-A` remains `closed` as a `Phase 0R` evaluation packet.

This rewrite replaces the earlier shallow `0R-A` wording with the actual standard required for future implementation work:

- read the upstream source directly
- salvage all meaningful value
- omit only when the surface is:
  - an inferior duplicate
  - superseded by a stronger retained donor
  - off topic to HyperTwist's retained product scope
  - host-shell glue with no durable architecture value
- record the rationale every time something is not promoted

For these seven repos, this document is now the canonical `integration-facing` authority.

Before a future instance implements any `0R-A` repo, it must read:

1. this document for source-value extraction and exclusion rationale
2. [REPO_LICENSE_TRACKING.md](C:/HyperTwist/docs/REPO_LICENSE_TRACKING.md:1) for license, attribution, notice, and provenance obligations
3. [HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md](C:/HyperTwist/docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md:1) for sequencing

## Purpose

This packet redoes `Phase 0R-A` as a true deep source parsing packet for:

- `HactarCE/Hyperspeedcube`
- `kkoomen/qbr`
- `vivaansinghvi07/rubix-cube-solver`
- `Aarav2709/KubeTimr`
- `roice3/MagicTile`
- `roice3/Magic120Cell`
- `roice3/MagicCube5D`

It answers, repo by repo:

- what was actually read in source
- what value HyperTwist should salvage
- what is subordinate, duplicate, inferior, or off topic
- why that non-promotion decision was made
- which repo should own a domain when two repos overlap
- how the repo should enter `Phase 2R`, `Phase 3R`, or `Phase 6R`

## 2026-05-14 intake and product-fit clarification

This packet is source evidence plus evaluation judgment.

It must not be read as proof that any row here was automatically:

- favored merely because it was bookmarked earlier
- favored merely because it was queued earlier
- retained without further judgment
- a product fit by default
- implementation-authorized by default
- already implemented in first-party surfaces

Future instances must keep the evaluation states separate:

- bookmarked = intake only
- queued = sequencing only
- source-read = evidence gathered
- retained = survived evaluation with preserved value
- product-fit = separate judgment about HyperTwist direction
- implementation-authorized = separate bounded build approval
- implemented = landed in first-party product surfaces

Every future evaluation refresh or reuse of this packet should keep explicit:

- exact source basis read
- licensing posture
- preserved subsystem ideas
- subordinate or later value
- explicit product-fit verdict
- explicit non-promotion decisions with rationale
- retention posture
- owner-lane placement
- recommended implementation phase and realization depth if retained
- what the repo should never be mistaken for

Use [HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md:1) as the canonical anti-conflation doctrine and [HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md:1) as the coordinator-facing routing rule.

## Storage boundary

To stop future confusion, the storage boundary is now explicit:

- `this packet doc`: source-value extraction, implementation posture, overlap resolution, exclusion rationale
- [REPO_LICENSE_TRACKING.md](C:/HyperTwist/docs/REPO_LICENSE_TRACKING.md:1): repo-row license, attribution, copyright, notice, asset-term, and provenance obligations
- [HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md](C:/HyperTwist/docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md:1): row state and next-step board
- [HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md](C:/HyperTwist/docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md:1): packet sequencing and restart phases
- [HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md](C:/HyperTwist/docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md:1): cross-location authority routing

This packet must carry a concise per-repo licensing snapshot so an implementation-facing instance sees the legal posture at handoff time.
Full legal obligations still belong only in [REPO_LICENSE_TRACKING.md](C:/HyperTwist/docs/REPO_LICENSE_TRACKING.md:1).
Deep source-value extraction does not belong in the license tracker.

## Packet licensing snapshot

- `HactarCE/Hyperspeedcube`: `MIT OR Apache-2.0`
- `kkoomen/qbr`: `MIT`
- `vivaansinghvi07/rubix-cube-solver`: `MIT`
- `Aarav2709/KubeTimr`: `MIT`
- `roice3/MagicTile`: `MIT`
- `roice3/Magic120Cell`: `MIT`
- `roice3/MagicCube5D`: `MIT`

## Inputs used

This rewrite used:

- current reset docs in `C:\HyperTwist\docs`
- current mirrors under `C:\Workspaces\HyperTwist\mirrors\permissive`
- the existing parse-side dossier files for the seven repos
- checked live Unreal surfaces under:
  - `C:\HyperTwist\UnrealHyperTwist\Source`
  - `C:\HyperTwist\UnrealHyperTwist\Content\HyperTwistTraining\MaterializedCatalog`

## Live-state result

Current live-evidence check result for all seven `0R-A` repos:

- no exact live-surface match found in checked Unreal source or materialized catalog

That means:

- none of these seven are currently proven live in checked Unreal surfaces
- all seven remain retained candidates, not landed implementation lanes

## Deep-source evaluation standard from this packet forward

From `0R-A` onward, a repo packet is not complete unless it records:

- exact source surfaces inspected
- primary value to keep
- secondary value that may be useful later
- explicit non-promotion decisions
- reason for each non-promotion:
  - `inferior duplicate`
  - `superseded by stronger retained donor`
  - `off topic`
  - `host-shell glue / legacy packaging`
  - `implementation detail better reauthored first-party`

Future `Phase 0R` packets should follow this same standard.

## Packet-wide hierarchy

This packet does not treat all seven repos as equal.

| Domain | Primary retained owner | Secondary retained owner | Non-promotion rule |
| --- | --- | --- | --- |
| Hyper runtime architecture | `HactarCE/Hyperspeedcube` | `roice3/MagicTile` | `MagicTile`, `Magic120Cell`, and `MagicCube5D` must not displace `Hyperspeedcube` as the runtime-side foundation because the inspected Hyperspeedcube core is more modular and more general. |
| Recognition calibration nucleus | `kkoomen/qbr` | `vivaansinghvi07/rubix-cube-solver` | `rubix-cube-solver` complements `qbr`; it does not replace it because `qbr` is the cleaner calibration and color-normalization anchor. |
| Browser correction / explanation / NxN solve staging | `vivaansinghvi07/rubix-cube-solver` | `kkoomen/qbr` | `qbr` is the capture nucleus, not the explanation shell. |
| Timer / inspection / session stats / splits | `Aarav2709/KubeTimr` | none in `0R-A` | Do not widen it into a general training-platform owner. Keep it as a bounded subsystem donor. |
| Non-Euclidean geometry / topology / macro transport | `roice3/MagicTile` | `roice3/Magic120Cell` | `MagicTile` owns this lane because its inspected geometry/topology and macro remapping logic is broader. |
| Specialized `4D` interaction patterns | `roice3/Magic120Cell` | `roice3/MagicTile` | Use for concrete `120-cell` interaction, visibility, and piece-finding patterns, not as a broader runtime foundation. |
| Specialized `5D` cube-family state / macro UX | `roice3/MagicCube5D` | none in `0R-A` | Keep this repo for `5D` state encoding and macro/progress semantics, not as a general hyper runtime owner. |

## Packet outcome summary

- retained: `7`
- discarded: `0`
- newly proven live: `0`

Most important scheduling consequence:

- `Aarav2709/KubeTimr` remains the earliest straight permissive subsystem implementation candidate after `Phase 2R`
- `HactarCE/Hyperspeedcube`, `kkoomen/qbr`, and `roice3/MagicTile` remain architecture-shaping anchors
- `vivaansinghvi07/rubix-cube-solver`, `roice3/Magic120Cell`, and `roice3/MagicCube5D` remain retained but subordinate or specialized

## Repo evaluations

### `HactarCE/Hyperspeedcube`

Inspected source surfaces:

- [Cargo.toml](C:/Workspaces/HyperTwist/mirrors/permissive/HactarCE/Hyperspeedcube/Cargo.toml:1)
- [crates/hyperpuzzle_core/src/lib.rs](C:/Workspaces/HyperTwist/mirrors/permissive/HactarCE/Hyperspeedcube/crates/hyperpuzzle_core/src/lib.rs:1)
- [crates/hyperpuzzlescript/src/lib.rs](C:/Workspaces/HyperTwist/mirrors/permissive/HactarCE/Hyperspeedcube/crates/hyperpuzzlescript/src/lib.rs:1)
- [crates/hypuz_notation/src/lib.rs](C:/Workspaces/HyperTwist/mirrors/permissive/HactarCE/Hyperspeedcube/crates/hypuz_notation/src/lib.rs:1)
- [crates/hypershape/src/lib.rs](C:/Workspaces/HyperTwist/mirrors/permissive/HactarCE/Hyperspeedcube/crates/hypershape/src/lib.rs:1)
- [crates/hyperpuzzle_impl_symmetric/src/spec.rs](C:/Workspaces/HyperTwist/mirrors/permissive/HactarCE/Hyperspeedcube/crates/hyperpuzzle_impl_symmetric/src/spec.rs:1)
- [crates/hyperpuzzle_impl_symmetric/src/twist_system.rs](C:/Workspaces/HyperTwist/mirrors/permissive/HactarCE/Hyperspeedcube/crates/hyperpuzzle_impl_symmetric/src/twist_system.rs:1)
- [crates/hyperpuzzle_view/src/lib.rs](C:/Workspaces/HyperTwist/mirrors/permissive/HactarCE/Hyperspeedcube/crates/hyperpuzzle_view/src/lib.rs:1)
- [crates/hyperpuzzle_view/src/replay_event.rs](C:/Workspaces/HyperTwist/mirrors/permissive/HactarCE/Hyperspeedcube/crates/hyperpuzzle_view/src/replay_event.rs:1)
- [crates/hyperpuzzle_view/src/simulation/nd_euclid.rs](C:/Workspaces/HyperTwist/mirrors/permissive/HactarCE/Hyperspeedcube/crates/hyperpuzzle_view/src/simulation/nd_euclid.rs:1)
- [crates/hyperpuzzle_view/src/view/nd_euclid.rs](C:/Workspaces/HyperTwist/mirrors/permissive/HactarCE/Hyperspeedcube/crates/hyperpuzzle_view/src/view/nd_euclid.rs:1)
- [crates/hyperpuzzle_log/src/verify.rs](C:/Workspaces/HyperTwist/mirrors/permissive/HactarCE/Hyperspeedcube/crates/hyperpuzzle_log/src/verify.rs:1)
- [crates/hyperstats/src/lib.rs](C:/Workspaces/HyperTwist/mirrors/permissive/HactarCE/Hyperspeedcube/crates/hyperstats/src/lib.rs:1)

High-value salvage:

- the repo is already partitioned like a platform: core puzzle model, puzzle DSL, notation layer, view state, simulation, verification, and stats
- `hyperpuzzle_core` is the strongest current donor for engine boundary design, catalog structure, naming/tagging, scramble constants, and shared puzzle semantics
- `Hyperpuzzlescript` is major value, not trivia: HyperTwist should keep the idea of a first-party puzzle-definition DSL and built-in puzzle package layer
- `hypuz_notation` is a direct donor for notation parsing/serialization families, feature gates, generalized rotations, and transform-aware move grammar
- `hyperpuzzle_impl_symmetric` contributes the strongest current model for symmetric twist systems, constraint handling, factor/product puzzle specs, axis/pole naming, and transform-constrained twisting
- `hypershape` contributes higher-dimensional slicing and shape math
- `hyperpuzzle_view` contributes replay-event taxonomy, drag/twist view-state semantics, transient camera handling, and partial-twist simulation patterns
- `hyperpuzzle_log` contributes solve verification, scramble verification, randomness-beacon posture, and timestamp/trust thinking
- `hyperstats` contributes PB storage and category modeling for speed/FMC/blind style stats

Subordinate or later value:

- host-shell and packaging crates in the workspace are secondary compared with the domain crates above
- app-level string/resource packaging is real project glue, but it is not where the strategic donor value sits for HyperTwist right now

Non-promotion decisions and rationale:

- do not transplant the whole Rust application shell: `host-shell glue / implementation detail better reauthored first-party`
- do not let `MagicTile`, `Magic120Cell`, or `MagicCube5D` override this repo for runtime-core, notation, or replay schema: `superseded by stronger retained donor`
- do not copy the exact official-build pathing or file-baking arrangement: `implementation detail better reauthored first-party`

Integration call:

- retain as the primary runtime-side hyper foundation anchor
- use it in `Phase 2R` to freeze catalog, DSL, notation, replay, verification, and simulation contracts
- schedule implementation extraction in `Phase 6R`

### `kkoomen/qbr`

Inspected source surfaces:

- [src/qbr.py](C:/Workspaces/HyperTwist/mirrors/permissive/kkoomen/qbr/src/qbr.py:1)
- [src/video.py](C:/Workspaces/HyperTwist/mirrors/permissive/kkoomen/qbr/src/video.py:1)
- [src/colordetection.py](C:/Workspaces/HyperTwist/mirrors/permissive/kkoomen/qbr/src/colordetection.py:1)
- [src/helpers.py](C:/Workspaces/HyperTwist/mirrors/permissive/kkoomen/qbr/src/helpers.py:1)
- [src/config.py](C:/Workspaces/HyperTwist/mirrors/permissive/kkoomen/qbr/src/config.py:1)
- [src/constants.py](C:/Workspaces/HyperTwist/mirrors/permissive/kkoomen/qbr/src/constants.py:1)

High-value salvage:

- persistent per-user cube palette calibration
- dominant-color extraction with `kmeans`
- LAB conversion plus `CIEDE2000` distance matching for perceptual color classification
- contour filtering for square-like stickers
- the center-neighbor heuristic that detects a `3x3` face by finding the contour with nine neighbors including itself
- stable left-to-right, top-to-bottom contour sorting after detection
- preview-state averaging and majority stabilization to reduce flicker and bad reads
- scan completeness validation by enforcing nine occurrences of each color
- BGR-to-notation mapping after normalization

Subordinate or later value:

- direct webcam UI loop, text drawing, and terminal interaction are usable references but not the core donor value
- the direct solve shell around the scanner is secondary to the recognition pipeline itself

Non-promotion decisions and rationale:

- do not promote `qbr.py` as a product-shell donor: `host-shell glue`
- do not treat the direct solver invocation as the main reason to keep the repo: `off topic` to the repo's strongest donor value, which is capture/calibration/state extraction
- do not let `qbr` own the full multi-size explanation/browser lane: `superseded by stronger retained donor` (`vivaansinghvi07/rubix-cube-solver`)

Integration call:

- retain as the primary recognition calibration anchor
- use it in `Phase 2R` to freeze calibration, perceptual color matching, contour ordering, and scan-state contracts
- schedule implementation extraction in `Phase 6R`

### `vivaansinghvi07/rubix-cube-solver`

Inspected source surfaces:

- [backend/cv.py](C:/Workspaces/HyperTwist/mirrors/permissive/vivaansinghvi07/rubix-cube-solver/backend/cv.py:1)
- [backend/server.py](C:/Workspaces/HyperTwist/mirrors/permissive/vivaansinghvi07/rubix-cube-solver/backend/server.py:1)
- [backend/test.py](C:/Workspaces/HyperTwist/mirrors/permissive/vivaansinghvi07/rubix-cube-solver/backend/test.py:1)
- [frontend/src/script.js](C:/Workspaces/HyperTwist/mirrors/permissive/vivaansinghvi07/rubix-cube-solver/frontend/src/script.js:1)

High-value salvage:

- a richer CV reconstruction pipeline than `qbr`, including contour filtering, angle grouping, face grouping, interpolation of missing squares, and explicit invalid-read guardrails
- `ImageToCube` frame accumulation and voting rather than single-frame commitment
- state scoring against a six-state rotation order to stabilize which cube orientation is currently being observed
- support for `2x2`, `3x3`, and larger `NxN` solve staging
- websocket protocol for `init`, `frame`, `finish`, and `solve`
- move normalization and conversion into TwistySim-readable notation, including wide turns, middle-layer conversions, and rear-side layer normalization
- mapping solver pipeline stages to human-readable explanations
- browser-side correction/edit/play flow for validating and correcting inferred state before solve playback

Subordinate or later value:

- the exact DOM shell is secondary to the protocol and correction flow
- the exact TwistySim coupling is useful, but HyperTwist should keep the move-normalization contract more than the library tie-in

Non-promotion decisions and rationale:

- do not promote this repo over `qbr` as the primary calibration nucleus: `superseded by stronger retained donor`
- do not promote the browser shell as a direct product-shell donor: `host-shell glue`
- do not treat the exact frontend stack as required: `implementation detail better reauthored first-party`

Integration call:

- retain as the secondary recognition and reconstruction companion behind `qbr`
- use it in `Phase 2R` to freeze browser correction, websocket session flow, frame voting, and explanation contracts
- schedule implementation extraction in `Phase 6R`

### `Aarav2709/KubeTimr`

Inspected source surfaces:

- [src/timingEngine.ts](C:/Workspaces/HyperTwist/mirrors/permissive/Aarav2709/KubeTimr/src/timingEngine.ts:1)
- [src/statsEngine.ts](C:/Workspaces/HyperTwist/mirrors/permissive/Aarav2709/KubeTimr/src/statsEngine.ts:1)
- [src/splits.ts](C:/Workspaces/HyperTwist/mirrors/permissive/Aarav2709/KubeTimr/src/splits.ts:1)
- [src/scrambleEngine.ts](C:/Workspaces/HyperTwist/mirrors/permissive/Aarav2709/KubeTimr/src/scrambleEngine.ts:1)
- [src/persistence.ts](C:/Workspaces/HyperTwist/mirrors/permissive/Aarav2709/KubeTimr/src/persistence.ts:1)
- [src/ui/hooks/useTimer.ts](C:/Workspaces/HyperTwist/mirrors/permissive/Aarav2709/KubeTimr/src/ui/hooks/useTimer.ts:1)
- [src/ui/components/VirtualReplay.tsx](C:/Workspaces/HyperTwist/mirrors/permissive/Aarav2709/KubeTimr/src/ui/components/VirtualReplay.tsx:1)
- [src/ui/components/StatsPanel.tsx](C:/Workspaces/HyperTwist/mirrors/permissive/Aarav2709/KubeTimr/src/ui/components/StatsPanel.tsx:1)
- [src/ui/components/SplitEditor.tsx](C:/Workspaces/HyperTwist/mirrors/permissive/Aarav2709/KubeTimr/src/ui/components/SplitEditor.tsx:1)
- [src/ui/components/ScrambleVisualizationModal.tsx](C:/Workspaces/HyperTwist/mirrors/permissive/Aarav2709/KubeTimr/src/ui/components/ScrambleVisualizationModal.tsx:1)

High-value salvage:

- a clean timer-state machine with inspection, `+2`, and `DNF` handling
- held-to-start control semantics for keyboard and touch
- rolling stats logic for `mo3`, `ao5`, `ao12`, `ao50`, `ao100`, `ao1000`, and `moXAo5`
- per-session PB tracking and chronological timeline construction
- split-phase normalization, ordering validation, capture merging, and per-phase duration calculation
- method presets for `CFOP`, `Roux`, `ZZ`, and `Petrus`
- async scramble prefetching and cache rotation for WCA events
- persistence fallback chain: IndexedDB, then local storage, then memory
- bounded `NxN` scramble visualization logic including wide turns, middle layers, and rotations

Subordinate or later value:

- the UI layout and styling is secondary to the subsystem logic
- the scramble visualization surface is useful, but secondary to the timing/splits/stats model

Non-promotion decisions and rationale:

- do not promote the React UI shell as the main donor: `host-shell glue`
- do not keep the mock replay data generation in `VirtualReplay` as a serious donor surface: `inferior duplicate`
- do not widen `KubeTimr` into a broader training-platform owner: `off topic` relative to the repo's strongest timer/session value
- do not bind HyperTwist permanently to the exact `cubing/scramble` package seam: `implementation detail better reauthored first-party`

Integration call:

- retain as a focused subsystem donor
- use it in `Phase 2R` to freeze timer, inspection, split, stats, and persistence contracts
- treat it as the earliest `0R-A` repo eligible for direct `Phase 3R` permissive implementation

### `roice3/MagicTile`

Inspected source surfaces:

- [MagicTile/Puzzle/Puzzle.cs](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/MagicTile/MagicTile/Puzzle/Puzzle.cs:1)
- [MagicTile/Puzzle/Loader.cs](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/MagicTile/MagicTile/Puzzle/Loader.cs:1)
- [MagicTile/Puzzle/State.cs](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/MagicTile/MagicTile/Puzzle/State.cs:1)
- [MagicTile/Puzzle/TopologyAnalyzer.cs](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/MagicTile/MagicTile/Puzzle/TopologyAnalyzer.cs:1)
- [MagicTile/Puzzle/Twisting/TwistHandler.cs](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/MagicTile/MagicTile/Puzzle/Twisting/TwistHandler.cs:1)
- [MagicTile/Puzzle/Twisting/Macro.cs](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/MagicTile/MagicTile/Puzzle/Twisting/Macro.cs:1)
- [R3/R3.Core/Geometry/Tiling.cs](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/MagicTile/R3/R3.Core/Geometry/Tiling.cs:1)
- [R3/R3.Core/Geometry/Polytope.cs](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/MagicTile/R3/R3.Core/Geometry/Polytope.cs:1)
- [R3/R3.Core/Math/Mobius.cs](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/MagicTile/R3/R3.Core/Math/Mobius.cs:1)
- [R3/R3.Core/Math/Matrix4D.cs](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/MagicTile/R3/R3.Core/Math/Matrix4D.cs:1)
- [R3/R3.Core/Honeycombs/H3.cs](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/MagicTile/R3/R3.Core/Honeycombs/H3.cs:1)

High-value salvage:

- the strongest current non-Euclidean and topology donor in the packet
- the puzzle builder pattern: tiling generation, master/slave cells, state-calculation cell selection, topology pass, sticker slicing, and twist-data registration
- topology analysis across logical faces, edges, and vertices, including identification merging and Euler characteristic calculation
- state matrix persistence and sticker toggle semantics
- animated twist handling, undo/redo-aware twist history integration, setup-move unwinding, and solve replay behavior
- macro recording and, more importantly, macro remapping through `Mobius` and isometry transforms across reflected or reoriented views
- tiling generation with face/vertex/edge-centered projections and dual-tiling support
- `Mobius` and `Matrix4D` math useful for non-Euclidean interaction and higher-dimensional rotation control
- hyperbolic honeycomb and skew-polyhedron construction patterns that widen HyperTwist beyond ordinary cube families

Subordinate or later value:

- legacy persistence dialogs and XML log plumbing are useful references, but not the main value
- renderer invalidation and host-specific texture refresh logic are lower-priority implementation detail

Non-promotion decisions and rationale:

- do not promote the WinForms/OpenTK shell as a product-shell donor: `host-shell glue`
- do not promote the exact XML persistence format as a first-party format requirement: `implementation detail better reauthored first-party`
- do not let `MagicTile` replace `Hyperspeedcube` as the runtime-base donor: `superseded by stronger retained donor`

Integration call:

- retain as the primary non-Euclidean, topology, and macro-transport donor
- use it in `Phase 2R` to freeze topology, geometry-family, and transform-aware macro concepts
- schedule implementation extraction in `Phase 6R`

### `roice3/Magic120Cell`

Inspected source surfaces:

- [Magic120Cell/cubeFrame.cpp](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/Magic120Cell/Magic120Cell/cubeFrame.cpp:1)
- [Magic120Cell/workFiles/magic120Cell.cpp](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/Magic120Cell/Magic120Cell/workFiles/magic120Cell.cpp:1)
- [Magic120Cell/workFiles/puzzle.h](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/Magic120Cell/Magic120Cell/workFiles/puzzle.h:1)
- [Magic120Cell/workFiles/cell.cpp](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/Magic120Cell/Magic120Cell/workFiles/cell.cpp:1)
- [geometryLib/puzzle/twist.h](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/Magic120Cell/geometryLib/puzzle/twist.h:1)
- [geometryLib/puzzle/twistHistory.cpp](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/Magic120Cell/geometryLib/puzzle/twistHistory.cpp:1)
- [geometryLib/puzzle/state.h](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/Magic120Cell/geometryLib/puzzle/state.h:1)
- [Magic120CellGui/MainFrame.cs](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/Magic120Cell/Magic120CellGui/MainFrame.cs:1)

High-value salvage:

- explicit `120-cell` visibility families: tori, `4-cube` cells, layers, and rings
- concrete `4D` hypercube overlay and cell grouping logic
- a reusable `CPuzzle` base pattern for settings changes, save/load, highlighting, rotate lifecycle, scramble/reset, solved-state gating, and current-view rotation tracking
- `Cell` rendering and twisting behavior that propagates twist consequences into adjacent cells while also handling per-face fading and logical/physical visibility interactions
- twist encoding around sticker hashes, left/right direction, view rotations, and slice masks
- state models for full-color and antipodal-color puzzle modes
- interaction semantics that are strategically valuable even if the shell is not:
  - click sticker to twist cell
  - `Ctrl+Click` for `4D` recentering / view rotation
  - `Shift+Click` piece highlighting
  - `Shift+Ctrl+Click` piece-finding behavior

Subordinate or later value:

- the old WinForms menu shell is secondary to the interaction semantics it exposes
- direct OpenGL host plumbing is lower priority than the puzzle, visibility, and interaction model

Non-promotion decisions and rationale:

- do not promote the WinForms shell as a product donor: `host-shell glue`
- do not promote `Magic120Cell` over `Hyperspeedcube` or `MagicTile` as the primary hyper foundation: `superseded by stronger retained donor`
- do not treat it as the packet's main macro donor: `inferior duplicate` relative to `MagicTile` and `MagicCube5D` for macro-focused value

Integration call:

- retain as a specialized `4D` interaction donor
- use it in `Phase 2R` for `4D` view rotation, visibility, piece-finding, and logical-vs-physical display contracts
- schedule implementation extraction later in `Phase 6R`, after `Hyperspeedcube` and `MagicTile`

### `roice3/MagicCube5D`

Inspected source surfaces:

- [src/MagicCube5D/workFiles/cube5D.cpp](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/MagicCube5D/src/MagicCube5D/workFiles/cube5D.cpp:1)
- [src/MagicCube5D/workFiles/twist.h](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/MagicCube5D/src/MagicCube5D/workFiles/twist.h:1)
- [src/MagicCube5D/workFiles/twist.cpp](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/MagicCube5D/src/MagicCube5D/workFiles/twist.cpp:1)
- [src/MagicCube5D/workFiles/stateTransformer.h](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/MagicCube5D/src/MagicCube5D/workFiles/stateTransformer.h:1)
- [src/MagicCube5D/workFiles/stateTransformer.cpp](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/MagicCube5D/src/MagicCube5D/workFiles/stateTransformer.cpp:1)
- [src/MagicCube5D/cubeFrame.cpp](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/MagicCube5D/src/MagicCube5D/cubeFrame.cpp:1)
- [src/MagicCubeGui/MainFrame.cs](C:/Workspaces/HyperTwist/mirrors/permissive/roice3/MagicCube5D/src/MagicCubeGui/MainFrame.cs:1)

High-value salvage:

- compact `5D` state encoding and decoding between sticker arrays and state matrices
- `5D` face-offset and cubie-index mapping logic
- click-twice twist derivation from cubie offsets and axis extraction
- `Ctrl+Click` view rotation semantics around the fifth axis
- macro lifecycle: record, persist, rename, delete, execute forward, execute reverse
- solved-progress tracking beyond binary solved/not solved, including cubie-class statistics
- cubie highlighting by color signatures
- explicit slice-mask semantics for higher-dimensional turns
- projection and stereo-mode controls that reveal how the donor thinks about `5D` inspection and display

Subordinate or later value:

- the exact WinForms shell is secondary
- the exact OpenGL stereo/anaglyph implementation is less important than the state, macro, and interaction model

Non-promotion decisions and rationale:

- do not promote the WinForms shell as a product donor: `host-shell glue`
- do not promote the stereo/anaglyph renderer as core packet value: `implementation detail better reauthored first-party`
- do not promote `MagicCube5D` above `Hyperspeedcube` or `MagicTile` as a general hyper runtime donor: `superseded by stronger retained donor`

Integration call:

- retain as a specialized `5D` cube-family UX and state donor
- use it in `Phase 2R` for `5D` state, macro, slice, solved-progress, and click-derived twist contracts
- schedule implementation extraction later in `Phase 6R`, after `Hyperspeedcube` and `MagicTile`

## Net packet interpretation changes

This rewrite makes the retained-set calls much more precise:

- `HactarCE/Hyperspeedcube` is not just "important"; it is the inspected primary owner for runtime architecture, DSL, notation, replay semantics, verification, and stats shape
- `kkoomen/qbr` is not just "scanner-ish"; it is the primary calibration and perceptual color-matching nucleus
- `vivaansinghvi07/rubix-cube-solver` is not redundant; it is the retained browser correction, frame-voting, and explanation companion
- `Aarav2709/KubeTimr` is not a platform; it is a high-quality early timer/splits/stats subsystem donor
- `roice3/MagicTile` is not just a later curiosity; it is the main non-Euclidean/topology and macro-transport donor
- `roice3/Magic120Cell` and `roice3/MagicCube5D` stay retained because they add specialized `4D` and `5D` interaction/state value that the packet should not discard, but neither is promoted over the stronger anchors

## Implementation guidance produced by this packet

`Phase 2R` must now create first-party contracts for:

- hyper runtime, DSL, notation, replay, verification, and stats from `Hyperspeedcube`
- recognition calibration from `qbr`
- reconstruction/browser correction/explanation from `rubix-cube-solver`
- timer, inspection, splits, persistence, and stats from `KubeTimr`
- topology, non-Euclidean geometry, and macro transforms from `MagicTile`
- specialized `4D` interaction from `Magic120Cell`
- specialized `5D` state/macro/progress semantics from `MagicCube5D`

`Phase 3R` should start with:

- `Aarav2709/KubeTimr`

`Phase 6R` should widen in this order:

1. `HactarCE/Hyperspeedcube`
2. `kkoomen/qbr`
3. `roice3/MagicTile`
4. `vivaansinghvi07/rubix-cube-solver`
5. `roice3/Magic120Cell`
6. `roice3/MagicCube5D`

## Packet-close result

`Packet 0R-A` is now:

- source-backed
- overlap-aware
- explicit about what to salvage
- explicit about what not to promote and why
- stored in the correct place for future integration work

It remains closed as an evaluation packet.

The next best clean move is to apply this same deep-source standard to the remaining `Phase 0R` packets before any new donor-shaped widening occurs.
3. open `Packet 0R-C` for the remaining non-permissive `Phase 0R` backlog while keeping `Phase 3R+` widening frozen
