# HyperTwist Classic Solver Oracle And Implementation Hierarchy Reconciliation - 2026-05-27

## Status

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

- `brownan/Rubiks-Cube-Solver`
- `efrantar/rob-twophase`
- `vivaansinghvi07/rubix-cube-solver`
- the landed first-party `Phase 6R-Q`, `Phase 6R-R`, and `Phase 6R-S` seams

It answers one narrow question:

- do the current compact-solver oracle surfaces require reopening the landed
  classic-cube reconstruction, recommendation, and correction packets before
  any future solver-adjacent packet is considered

Result:

- no product-code reopening is required
- yes selective authority backfill is required so the dependent canon layers
  keep the generalized solver-backend family non-live and keep the exact
  oracle split explicit

## 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\clean-room-specs\brownan-rubiks-cube-solver.oracle.md`
- `C:\HyperTwist\docs\arch\HYPERTWIST_PHASE6R_Q_RUBIX_CUBE_SOLVER_SOLVE_EXPLANATION_RECOMMENDATION_IMPLEMENTATION_PACKET_2026-05-23.md`
- `C:\HyperTwist\docs\arch\HYPERTWIST_PHASE6R_R_CLASSIC_CUBE_MULTI_FACE_CORRECTION_EXPLANATION_IMPLEMENTATION_PACKET_2026-05-24.md`
- `C:\HyperTwist\docs\arch\HYPERTWIST_PHASE6R_S_CLASSIC_CUBE_CORRECTION_RESOLUTION_CLOSURE_IMPLEMENTATION_PACKET_2026-05-24.md`
- `C:\Workspaces\HyperTwist\mirrors\restrictive\brownan\Rubiks-Cube-Solver\README.rst`
- `C:\Workspaces\HyperTwist\mirrors\restrictive\brownan\Rubiks-Cube-Solver\cube.c`
- `C:\Workspaces\HyperTwist\mirrors\restrictive\brownan\Rubiks-Cube-Solver\goal.c`
- `C:\Workspaces\HyperTwist\mirrors\restrictive\brownan\Rubiks-Cube-Solver\main.c`
- `C:\Workspaces\HyperTwist\mirrors\restrictive\efrantar\rob-twophase\README.md`
- `C:\Workspaces\HyperTwist\mirrors\restrictive\efrantar\rob-twophase\src\solve.cpp`
- current first-party solver-adjacent runtime surfaces under
  `C:\HyperTwist\UnrealHyperTwist\Source\UnrealHyperTwist`

## Slice-local verdict

| Slice | Primary authority | Secondary value kept | Route | Width | Result |
| --- | --- | --- | --- | --- | --- |
| Landed reconstruction, browser-shell, bounded solve-guidance, correction-explanation, and correction-resolution closure seams | `vivaansinghvi07/rubix-cube-solver` plus landed first-party `Phase 6R-Q/R/S` ownership | `brownan` as correctness oracle; `efrantar` as metric/performance comparator | existing landed permissive route | `F2` | unchanged live implementation owner |
| Compact classic-cube solver correctness, cube-state/search decomposition, heuristic-table planning, and future clean-room solver-core reference | `brownan/Rubiks-Cube-Solver` | `efrantar/rob-twophase` as performance and robot-metric comparator | `R4` now, `R3` only if explicitly reopened later | `F2` | unchanged restrictive oracle / clean-room-later authority |
| Two-phase metric, robot-execution, multi-thread, pruning, and throughput comparison | `efrantar/rob-twophase` | `brownan/Rubiks-Cube-Solver` as compact correctness anchor | `R4` | `F2` | unchanged restrictive comparator authority |

## Why no product-code reopening is required

### Landed first-party `Phase 6R-Q/R/S`

The current first-party classic-cube code does not claim a generalized solver
backend.

The active seams remain bounded:

- `RecommendationMode = bounded-stage-ladder-v1`
- `CorrectionMode = bounded-multi-face-correction-v1`
- reconstruction stays at `classic-face-vote-v1`

The packet docs already keep the broader generalized solver-backend family
deferred, so the current live code does not need rollback or replacement.

### `brownan/Rubiks-Cube-Solver`

`brownan` still correctly owns the compact correctness and heuristic-table
oracle slice.

The retained value remains strong in:

- compact from-scratch cube-state representation
- explicit move-elimination and turn-avoid rules
- corner and edge heuristic-table generation
- bounded correctness and move-optimality comparison use

`main.c` and `goal.c` make the retained role especially clear: this row is
valuable as a compact solver-core and heuristic-table benchmark, not as proof
that HyperTwist already landed a full in-house solver backend.

### `efrantar/rob-twophase`

`efrantar` still correctly owns the robot-metric and performance-comparison
slice.

The retained value remains strong in:

- explicit phase `1` / phase `2` search organization
- robot-oriented axial and quarter-turn metric support
- multi-threaded search splitting
- solver throughput and search-quality comparison

Those strengths do not make it the primary clean-room target for a future
first-party compact solver core. They remain the stronger comparator for
metric, throughput, and robot-execution expectations.

## Selective backfill result

### Earlier surfaces reopened

- `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\clean-room-specs\brownan-rubiks-cube-solver.oracle.md`

### Reason

Later classic-cube source comparison sharpened the exact solver-family split:

- the landed `Phase 6R-Q/R/S` seams are bounded shell/state families, not an
  implemented generalized solver backend
- `brownan` remains the primary compact correctness and heuristic-table oracle
- `efrantar` remains the primary metric, robot-execution, and performance
  comparator

### Change class

- cross-lane authority changed for the exact retained solver-family wording
- no repo-local extraction rollback
- no product-code change

### What remained valid

- the `0R-E` retained compact-solver oracle result remains valid
- the landed `Phase 6R-Q`, `Phase 6R-R`, and `Phase 6R-S` packets remain valid
- the current first-party classic-cube recommendation and correction code
  remains valid

### What changed

The dependent canon now needs to say the live classic-cube family more
explicitly:

- implemented now:
  - reconstruction
  - browser shell
  - bounded solve-guidance stage ladder
  - bounded correction and correction-resolution closure
- still non-live:
  - generalized solver backend ownership
  - compact correctness oracle ownership
  - robot-metric / performance solver comparator ownership

## Operational answer

Before any solver-adjacent implementation packet is opened, the correct move
was this evaluation and selective backfill pass first.

After this pass:

- do not reopen the live classic-cube code
- do not describe the current `Phase 6R-Q/R/S` stack as a generalized solver
  backend
- if a future solver-adjacent lane is reopened, treat `brownan` as the first
  compact correctness / heuristic-table oracle and treat `efrantar` as the
  metric and performance comparator rather than blurring them into one generic
  solver donor
