# HyperTwist Melinda 2x2x2x2 State And Flat Projection Hierarchy Reconciliation - 2026-05-27

## Status

This document is the source-backed reconciliation note for the current Melinda
`2x2x2x2` family across:

- `HactarCE/2x2x2x2-Scrambler`
- the landed first-party `HyperTwistCore` owner lane
- adjacent higher-dimensional runtime and legacy `4D` reference lanes that must
  not silently absorb or overstate this micro-domain

It answers one narrow question:

- does the current `HactarCE/2x2x2x2-Scrambler` source require reopening the
  landed bounded first-party Melinda owner lane before any future consumer or
  presentation packet is considered

Result:

- no product-code reopening is required
- yes selective authority backfill is required so candidate-era metadata no
  longer understates the already-landed Melinda owner lane
- the exact current owner slice remains narrow: Melinda state legality,
  parity/handedness and twist validation, move-family application,
  random-state generation, scramble-packet construction, and flat debug or
  teaching projection

## Source basis

- `C:\HyperTwist\docs\HYPERTWIST_PHASE_0R_PACKET_0R_D_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\hactarce-2x2x2x2-scrambler.model-a.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\outputs\hactarce-2x2x2x2-scrambler.model-b-reconciled.md`
- `C:\Workspaces\HyperTwist\mirrors\restrictive\HactarCE\2x2x2x2-Scrambler\README.md`
- `C:\Workspaces\HyperTwist\mirrors\restrictive\HactarCE\2x2x2x2-Scrambler\src\cljc\scrambler\puzzle\core.cljc`
- `C:\Workspaces\HyperTwist\mirrors\restrictive\HactarCE\2x2x2x2-Scrambler\src\cljc\scrambler\puzzle\moves.cljc`
- `C:\Workspaces\HyperTwist\mirrors\restrictive\HactarCE\2x2x2x2-Scrambler\src\cljc\scrambler\puzzle\state_generator.cljc`
- `C:\Workspaces\HyperTwist\mirrors\restrictive\HactarCE\2x2x2x2-Scrambler\src\cljc\scrambler\puzzle\permutation_utils.cljc`
- `C:\Workspaces\HyperTwist\mirrors\restrictive\HactarCE\2x2x2x2-Scrambler\src\cljs\scrambler\ui\flat_view.cljs`
- current first-party runtime and test authority under:
  - `C:\HyperTwist\UnrealHyperTwist\Source\UnrealHyperTwist\Public\HyperTwistCore\HyperTwistCoreLibrary.h`
  - `C:\HyperTwist\UnrealHyperTwist\Source\UnrealHyperTwist\Public\HyperTwistCore\HyperTwistCoreTypes.h`
  - `C:\HyperTwist\UnrealHyperTwist\Source\UnrealHyperTwist\Private\HyperTwistCore\HyperTwistCoreLibrary.cpp`
  - `C:\HyperTwist\UnrealHyperTwist\Source\UnrealHyperTwist\Tests\HyperTwistMelindaBound1CoreTest.cpp`
  - `C:\HyperTwist\UnrealHyperTwist\Source\UnrealHyperTwist\Tests\HyperTwistMelindaBound2CoreTest.cpp`
  - `C:\HyperTwist\UnrealHyperTwist\Source\UnrealHyperTwist\Tests\HyperTwistMelindaBound3CoreTest.cpp`
  - `C:\HyperTwist\UnrealHyperTwist\Source\UnrealHyperTwist\Tests\HyperTwistMelindaBound4CoreTest.cpp`

## Slice-local verdict

| Slice | Primary authority | Secondary value kept | Route | Width | Result |
| --- | --- | --- | --- | --- | --- |
| Melinda `2x2x2x2` state model, legality or handedness or twist rules, move-family application, and random-state generation | first-party `HyperTwistCore` lane grounded in `HactarCE/2x2x2x2-Scrambler` | legacy `magiccube4d` remains adjacent reference context only | `R3` | `F2` | unchanged live implementation owner |
| Melinda scramble-packet construction and flat debug or teaching projection | first-party `HyperTwistCore` lane grounded in `HactarCE/2x2x2x2-Scrambler` | legacy `magiccube4d` remains adjacent reference context only | `R3` | `F2` | unchanged live implementation owner |
| Broader `4D` runtime, interaction history, and generalized higher-dimensional ownership | adjacent higher-dimensional lanes | none required from this donor | existing adjacent routes | `F2` | unchanged adjacent owners |

## Why no product-code reopening is required

### `HactarCE/2x2x2x2-Scrambler`

The donor still owns the narrow Melinda micro-domain center of gravity:

- compact Melinda state encoding
- legality, parity, handedness, and twist conservation rules
- move-family semantics and exact application behavior
- solvable random-state generation
- flat debug or teaching projection

That retained slice remains correct. It does not widen into a general hyper
runtime, trainer shell, or broader `4D` application owner.

### Landed first-party owner lane

The first-party owner lane is already live and closed in current code:

- public owner surfaces exist in `HyperTwistCoreLibrary.h` and
  `HyperTwistCoreTypes.h`
- first-party state validation is exposed through
  `UHyperTwistCoreLibrary::ValidatePuzzleState`
- first-party Melinda scramble-packet construction is exposed through
  `BuildMelindaScramblePacketFromGeneratedState` and
  `BuildMelindaScramblePacketFromTransformSequence`
- first-party flat projection is exposed through `BuildMelindaFlatProjection`
- the repo-local reconciled note already records `Bounds 1-4 closed`
- focused automation exists for all four Melinda bounds

That means the same-bound owner work is already landed. This pass does not find
an owner-side gap that justifies reopening it.

### Current adjacent owner boundaries

The current adjacent-owner split is also still correct:

- `Hyperspeedcube` remains the broader higher-dimensional runtime anchor
- `magiccube4d` remains legacy `4D` reference context, not the owner of the
  narrow retained Melinda state or flat-projection slice
- the Melinda lane stays a small owned core inside `HyperTwistCore`, not a new
  general runtime foundation

Those boundaries do not need to be reopened for this lane.

## Selective backfill result

### Earlier packet reopened

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

### Earlier standing note reopened

- `C:\Workspaces\HyperTwist\clean-room-specs\hactarce-2x2x2x2-scrambler.model-a.md`

### Manifest row reopened

- `C:\Workspaces\HyperTwist\repos.manifest.json`

### Additional canon reopened

- `C:\HyperTwist\docs\REPO_LICENSE_TRACKING.md`
- `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\FEATURE_REGISTRY.md`

### Reason

The landed lane itself was already correct. The stale part was the metadata:

- the manifest row still preserved the older reset-era wording
- the tracker still described the row mainly as a donor target instead of a
  closed landed owner slice
- the feature registry did not explicitly record the Melinda bounded owner
  family in its current live form
- the canonical `Model A` handoff needed an explicit landed-status reminder so
  future clean work does not accidentally reopen the closed bounds

### Change class

- repo-local extraction did not change
- landed owner interpretation was confirmed rather than reversed
- dependent canon was sharpened so the lane stays narrow and clearly closed
- no product-code change occurred

### What remained valid

- the restrictive `GPL-3.0` clean-room route remained valid
- the original `0R-D` decision to keep this lane narrow remained valid
- the repo-local `Bounds 1-4 closed` conclusion remained valid

### What changed

The dependent canon now makes the current landed role explicit:

- keep Melinda ownership inside `HyperTwistCore`
- keep broader higher-dimensional runtime ownership with adjacent live lanes
- keep `magiccube4d` as legacy reference context rather than a retained winner
  for this narrow slice
- do not reopen the closed `Bound 1` through `Bound 4` sequence by default

## Propagation result

### Feature registry

Updated.

The registry now says what is actually live: first-party Melinda ownership is
real for state legality, random-state generation, move-family application,
scramble-packet construction, and flat debug or teaching projection behavior.

### 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, feature registry, manifest row, and canonical handoff
status were sharpened instead.

## Operational answer

Before any future Melinda consumer shell, generalized `4D` widening, or broader
higher-dimensional packet is considered, the correct move was this authority
backfill first.

After this pass:

- do not reopen `Bound 1`, `Bound 2`, `Bound 3`, or `Bound 4`
- do not reinterpret adjacent higher-dimensional reference context as a
  same-bound owner gap
- if later work is justified, scope it as a new consumer-owner or widening
  packet above the closed Melinda owner lane
