# HyperTwist Large-N Classic-Cube Hierarchy Reconciliation - 2026-05-27

## Status

This document is the source-backed reconciliation note for the current
large-`N` classic-cube family across:

- `ShellPuppy/RCube`
- the landed first-party `Hyperspeedcube`, `MagicTile`, `Magic120Cell`, and
  `MagicCube5D` seams
- the landed bounded classic-cube `Phase 6R-Q`, `Phase 6R-R`, and `Phase 6R-S`
  seams

It answers one narrow question:

- does the current `RCube` source require reopening already landed HyperTwist
  product packets before any future large-`N` classic-cube packet is
  considered

Result:

- no product-code reopening is required
- yes selective authority backfill is required so the retained large-`N`
  classic-cube slice is explicit and not blurred into the landed hyper-runtime
  or bounded classic-cube shell families

## Source basis

- `C:\HyperTwist\docs\HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md`
- `C:\HyperTwist\docs\REPO_LICENSE_TRACKING.md`
- `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\FEATURE_REGISTRY.md`
- `C:\Workspaces\HyperTwist\repos.manifest.json`
- `C:\Workspaces\HyperTwist\mirrors\restrictive\ShellPuppy\RCube\README.md`
- `C:\Workspaces\HyperTwist\mirrors\restrictive\ShellPuppy\RCube\RCube\Face.h`
- `C:\Workspaces\HyperTwist\mirrors\restrictive\ShellPuppy\RCube\RCube\Cube.h`
- `C:\Workspaces\HyperTwist\mirrors\restrictive\ShellPuppy\RCube\RCube\Cube.cpp`
- current first-party runtime and packet authority under:
  - `C:\HyperTwist\docs\ops\HYPERTWIST_IMPLEMENTATION_PHASE_1_KICKOFF.md`
  - `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\ARCHITECTURE.md`
  - `C:\HyperTwist\UnrealHyperTwist\Source\UnrealHyperTwist`

## Slice-local verdict

| Slice | Primary authority | Secondary value kept | Route | Width | Result |
| --- | --- | --- | --- | --- | --- |
| Landed hyper puzzle runtime, topology, and family-specific higher-dimensional profiles | first-party landed `Hyperspeedcube`, `MagicTile`, `Magic120Cell`, and `MagicCube5D` seams | none required from `RCube` | existing landed permissive route | `F2` | unchanged live implementation owner |
| Landed bounded classic-cube reconstruction, solve-guidance, correction-explanation, and correction-resolution shell/state seams | first-party landed `Phase 6R-Q`, `Phase 6R-R`, and `Phase 6R-S` seams | none required from `RCube` | existing landed permissive route | `F2` | unchanged live implementation owner |
| Large-`N` classic-cube center-stage planning, edge-pairing and parity handling, and virtual-rotation strategy for later widening | `ShellPuppy/RCube` | current first-party hyper-runtime families remain adjacent non-overlapping owners | `R4` now, `R3` only if an explicit clean-room packet is opened later | `F2` | restrictive benchmark/oracle authority kept explicit |

## Why no product-code reopening is required

### `ShellPuppy/RCube`

`RCube` is still the strongest retained source for one narrow slice:

- very large classic-cube solve framing with explicit `centers -> corners ->
  edges` staging
- center-move batching through quadrant-oriented commutator planning
- edge-pairing flow with dedicated parity-fix handling
- virtual face rotation through coordinate-system remapping instead of
  `N^2` sticker shuffling

That retained value is explicit in the current source:

- `README.md` documents the `centers -> corners -> edges` solve order and the
  large-`N` center-commutator strategy
- `README.md` and `Face.h` document the virtual face-orientation approach
- `Cube.h` exposes dedicated large-`N` center, edge, and parity routines such
  as `SolveCenters`, `SolveEdgesOdd`, `SolveEdgesEven`, and `FixParity`
- `Cube.cpp` shows the staged center progression and the edge/parity repair
  flow in actual code

Those strengths do not make `RCube` the owner of the currently landed
HyperTwist hyper-runtime families, and they do not prove a live first-party
large-`N` classic-cube runtime already exists.

### Landed hyper-runtime families

The currently landed `Hyperspeedcube`, `MagicTile`, `Magic120Cell`, and
`MagicCube5D` packets remain about:

- hyper puzzle catalog and notation
- replay verification and solve-proof seams
- topology-family contracts
- dedicated higher-dimensional family runtime and persistence profiles

Those are adjacent but non-overlapping with `RCube`'s retained large-`N`
classic-cube center/edge/parity slice.

So `RCube` does not reopen those landed packets.

### Landed classic-cube `Phase 6R-Q/R/S`

The landed `Phase 6R-Q`, `Phase 6R-R`, and `Phase 6R-S` seams remain bounded:

- browser-assisted reconstruction follow-up
- solve-guidance stage ladders
- correction explanation and correction-resolution closure

They do not claim to be a generalized large-`N` classic-cube solver backend.

So `RCube` also does not reopen the currently landed classic-cube shell/state
families.

## Selective backfill result

### Earlier packet reopened

- `C:\HyperTwist\docs\HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md`

### Reason

Later comparison against the now-landed HyperTwist runtime families sharpened
the exact retained `RCube` slice:

- `RCube` is not a generic donor for hyper-runtime or classic-cube shell-state
  widening
- `RCube` is the retained `A1` authority only for the narrower large-`N`
  classic-cube center/edge/parity and virtual-rotation strategy slice
- the current route is `R4`, not live implementation ownership

### Change class

- repo-local extraction did not change
- cross-lane authority wording was sharpened for the exact retained slice
- no cleanup interpretation changed
- no product-code change occurred

### What remained valid

- the original `0R-E` decision to keep `RCube` restrictive and non-live
  remained valid
- the current first-party hyper-runtime packets remained valid
- the current first-party classic-cube `Phase 6R-Q/R/S` seams remained valid

### What changed

The dependent canon now makes the exact non-live role explicit:

- keep `RCube` only as the retained large-`N` classic-cube benchmark/oracle
- keep hyper-runtime ownership with the already landed first-party
  higher-dimensional families
- keep classic-cube shell/state ownership with the already landed bounded
  `Phase 6R-Q/R/S` seams

## Propagation result

### Feature registry

Updated.

The registry now explicitly records the retained large-`N` classic-cube
center/edge/parity family instead of leaving that slice implicit in the older
`0R-E` packet alone.

### Cross-lane doctrine

No doctrine wording change was needed.

This pass applied the existing `A/R/F` hierarchy; it did not change the
hierarchy rules themselves.

### Skillization

No doctrine or `SKILLS.md` change was needed.

This pass did not create or reopen any command or skill surface.

### Legal evidence

No license-status or mirror-custody change occurred.

The repo-row tracker and manifest were sharpened instead.

## Operational answer

Before any future large-`N` classic-cube packet is opened, the correct move
was this evaluation and selective backfill pass first.

After this pass:

- do not reopen the live product code
- do not blur `RCube` into the landed hyper-runtime or bounded classic-cube
  shell/state families
- if HyperTwist later opens a true large-`N` classic-cube lane, start from the
  retained `RCube` center/edge/parity slice as `A1 + R4 + F2`, then decide
  whether a clean-room `R3` widening is actually justified
