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

Created on `2026-05-13`

## Status

`Packet 0R-D` is now `closed` as a `Phase 0R` evaluation packet.

This packet applies the same deep-source standard already established by `0R-A`, `0R-B`, and `0R-C`:

- 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 four repos, this document is now the canonical `governance and Model A authority` packet.

Interpretation clarification added on `2026-05-13`:

- the `do not promote`, `do not preserve literally`, and `non-promotion` wording in this packet is meant to protect boundaries, not to deter later `Model A` instances from writing richer clean-room handoffs
- future `Model A` instances should still extract the maximum durable value inside each retained restrictive lane
- if a scrubbed handoff undercaptures the retained domain, strengthen the handoff rather than forcing later `Model B` work to improvise
- the canonical doctrine for that reading now lives in [HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md](C:/HyperTwist/docs/HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md:1)

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

1. this document for source-value extraction, exclusion rationale, and clean-room lane selection
2. [REPO_LICENSE_TRACKING.md](C:/HyperTwist/docs/REPO_LICENSE_TRACKING.md:1) for repo-row legal and provenance obligations
3. the repo-specific scrubbed Model A handoff in `C:\Workspaces\HyperTwist\clean-room-specs\`
4. [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-D` as a true deep source parsing packet for:

- `cubing/alg.js`
- `cubing/twisty.js`
- `HactarCE/2x2x2x2-Scrambler`
- `kash/cubedesk`

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 restrictive rows overlap with already-retained permissive or boundary-sensitive lanes
- how the repo should enter `Phase 2R` and later `Phase 5R` clean-room implementation work

## 2026-05-14 intake, product-fit, and clean-room routing clarification

This packet is source evidence plus retained-lane 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
- entitled to maximum realization merely because it is restrictive
- a product fit by default
- implementation-authorized by default
- already implemented in first-party product surfaces

Future instances must keep the state vocabulary 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 = explicit approval for a bounded clean-room build lane
- implemented = landed in first-party product surfaces under explicit implementation authority

Ownership-versus-route rule:

- restrictive status does not automatically demote a repo beneath a permissive or boundary-sensitive alternative
- decide technical and product-fit ownership first
- decide clean-room and compliance routing second
- if a restrictive row wins technically, preserve that win and then route it through the correct clean-room discipline
- harder route does not mean weaker donor

For these restrictive rows, clean-room prompt packs, handoff files, or queue position are routing evidence only.

They are not proof of current implementation.

Future refreshes of this packet and its handoffs 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 clean-room 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 clean-room routing and implementation-state rule.

## Storage boundary

To stop future confusion, the storage boundary is explicit:

- `this packet doc`: source-value extraction, implementation posture, overlap resolution, exclusion rationale, and refreshed Model A scope
- [HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md](C:/HyperTwist/docs/HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md:1): canonical interpretation rule for future `Model A` max-value extraction and anti-over-narrowing guidance
- [REPO_LICENSE_TRACKING.md](C:/HyperTwist/docs/REPO_LICENSE_TRACKING.md:1): repo-row license, attribution, notice, publication, subtree, and provenance obligations
- `C:\Workspaces\HyperTwist\clean-room-specs\*.model-a.md`: the only scrubbed Model B handoff inputs for later clean-room implementation
- [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 is a `governance and Model A` authority doc, not a Model B implementation handoff.

Model B must not treat this document as a substitute for the scrubbed clean-room specs.

Future `Model A` work, however, should treat this packet and the canonical modus-operandi doc together:

- this packet defines repo-specific retained value and boundary protection
- the modus-operandi doc defines how to keep later `Model A` clean-room extraction rich rather than shallow

## Packet licensing snapshot

- `cubing/alg.js`: `GPL-3.0-or-later`
- `cubing/twisty.js`: `GPL-3.0-or-later`
- `HactarCE/2x2x2x2-Scrambler`: `GPL-3.0`
- `kash/cubedesk`: `GPLv3-or-later` in `README.md` and `LICENSE.md`, but `package.json` says `All Rights Reserved`

## Inputs used

This rewrite used:

- current reset docs in `C:\HyperTwist\docs`
- current restrictive mirrors under:
  - `C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\alg.js`
  - `C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\twisty.js`
  - `C:\Workspaces\HyperTwist\mirrors\restrictive\HactarCE\2x2x2x2-Scrambler`
  - `C:\Workspaces\HyperTwist\mirrors\restrictive\kash\cubedesk`
- the preexisting Model A handoffs under:
  - `C:\Workspaces\HyperTwist\clean-room-specs\cubing-alg-js.model-a.md`
  - `C:\Workspaces\HyperTwist\clean-room-specs\cubing-twisty-js.model-a.md`
  - `C:\Workspaces\HyperTwist\clean-room-specs\hactarce-2x2x2x2-scrambler.model-a.md`
  - `C:\Workspaces\HyperTwist\clean-room-specs\kash-cubedesk.model-a.md`
- 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 four `0R-D` repos:

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

Important nuance:

- first-party Unreal code does contain generic `2x2x2x2` topology identifiers
- that is not proof that `HactarCE/2x2x2x2-Scrambler` source or a direct donor implementation is already live

That means:

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

## Packet-wide hierarchy

This packet does not treat all four restrictive rows as equal.

| Domain | Primary retained owner | Secondary retained owner | Non-promotion rule |
| --- | --- | --- | --- |
| Algorithm language, parser, AST, validation, and interchange semantics | `cubing/alg.js` | none in `0R-D` | Do not let this row collapse into `cubing/cubing.js` custody. Keep it as a focused clean-room lane for algorithm-language behavior only. |
| Compact embedded viewer/player shell and observer-driven playback behavior | `cubing/twisty.js` | none in `0R-D` | Do not let this row displace `cubing/cubing.js` for classic-cubing semantics or `Hyperspeedcube` for the hyper runtime. Keep it as a compact playback clean-room lane. |
| Melinda `2x2x2x2` random-state, solvability, and flat debug semantics | `HactarCE/2x2x2x2-Scrambler` | none in `0R-D` | Keep it narrow. Do not widen it into a general runtime, trainer shell, or full hyper-puzzle foundation. |
| Trainer-session, solve/session/stats, smart-cube workflow, and match product-pattern extraction | `kash/cubedesk` | none in `0R-D` | Do not let the full CubeDesk app shell displace `Hyperspeedcube`, `qbr`, or the already-retained permissive trainer stack. Mine it selectively as a strategic clean-room donor. |

## Packet outcome summary

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

Most important scheduling consequences:

- the restrictive clean-room candidate backlog is now closed as a `Phase 0R` evaluation class
- all four rows remain `clean-room only`; none is approved for direct donor use
- all four Model A handoffs were refreshed from the deeper source read and remain the only Model B input surface
- the next clean packet is `0R-E`

## Repo evaluations

### `cubing/alg.js`

Inspected source surfaces:

- [README.md](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/alg.js/README.md:1)
- [package.json](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/alg.js/package.json:1)
- [src/parser.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/alg.js/src/parser.ts:1)
- [src/json.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/alg.js/src/json.ts:1)
- [src/algorithm/alg-part.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/alg.js/src/algorithm/alg-part.ts:1)
- [src/algorithm/block-move.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/alg.js/src/algorithm/block-move.ts:1)
- [src/algorithm/index.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/alg.js/src/algorithm/index.ts:1)
- [src/traversal.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/alg.js/src/traversal.ts:1)
- [src/validation.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/alg.js/src/validation.ts:1)
- [src/keyboard.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/alg.js/src/keyboard.ts:1)
- [src/url.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/alg.js/src/url.ts:1)

Licensing posture:

- `GPL-3.0-or-later`
- retain only as a focused clean-room parser and interchange donor
- Model B may only consume [cubing-alg-js.model-a.md](C:/Workspaces/HyperTwist/clean-room-specs/cubing-alg-js.model-a.md:1)

High-value salvage:

- the parse pipeline is cleanly layered: text input, parser output, JSON-to-object reconstruction, then optional validator passes
- the AST family is durable donor value: immutable `Sequence`, `Group`, `BlockMove`, `Commutator`, `Conjugate`, `Pause`, newline, and comment nodes
- `BlockMove` captures plain, inner-layer, and ranged-layer semantics in one compact move representation
- the traversal layer is much stronger than a basic parse tree walker; it already encodes invert, expand, structural equality, move coalescing, and canonical text serialization patterns
- `json.ts` adds a second interchange boundary beyond the parser itself, which matters if HyperTwist later wants serialized algorithm payloads independent of text form
- the validation layer carries real semantic rules for SiGN families, flat-alg restrictions, and layer-range legality
- keyboard-to-move mapping is an intentionally separate boundary rather than an accidental parser side effect
- the URL layer shows a production-shaped serialization scheme plus link generation for alg playback/editor endpoints

Subordinate or later value:

- example, debug, HTML test, and webpack packaging surfaces are not the retained center of gravity
- the specific keycode map is useful, but should remain remappable rather than becoming a canonical first-party constant
- the `alg.cubing.net` link surface is valuable as an interchange pattern, not as a primary runtime owner

Non-promotion decisions and rationale:

- do not collapse this repo into the broader `cubing/cubing.js` lane for custody purposes: `boundary discipline`
- do not use the exact parser or grammar source directly in a proprietary core: `clean-room only`
- do not promote browser/demo scaffolding as donor value: `host-shell glue`
- do not treat `alg.js` as a runtime or viewer owner: `off topic` relative to its strongest parser/AST/interchange value

Integration call:

- retain as the primary restrictive clean-room donor for algorithm-language behavior
- use it in `Phase 2R` to freeze first-party parser, AST, validation, serialization, keyboard-input, and URL/interchange contracts
- refresh the Model A handoff with the deeper node-family and traversal findings
- if later implementation proceeds, schedule Model B work in `Phase 5R`, not as direct donor use
- current `2026-05-27` reconciliation overlay:
  - repo-local extraction unchanged
  - the first-party `HyperTwistAlgorithm/*` owner lane is now verified live and
    closed through `Bound 4`
  - current training-runtime parse/store/serialize usage is a consumer seam,
    not a same-bound owner gap
  - keep broader classic-cubing semantics with `cubing/cubing.js` and
    viewer/player ownership with `cubing/twisty.js`
  - do not reopen `Bound 1` through `Bound 4` by default; later work must be a
    new consumer-owner or shell packet if justified

### `cubing/twisty.js`

Inspected source surfaces:

- [README.md](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/twisty.js/README.md:1)
- [package.json](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/twisty.js/package.json:1)
- [src/twisty.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/twisty.js/src/twisty.ts:1)
- [src/widget.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/twisty.js/src/widget.ts:1)
- [src/anim.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/twisty.js/src/anim.ts:1)
- [src/puzzle.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/twisty.js/src/puzzle.ts:1)
- [src/cursor.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/twisty.js/src/cursor.ts:1)
- [src/3D/twisty3D.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/twisty.js/src/3D/twisty3D.ts:1)
- [src/3D/cube3D.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/cubing/twisty.js/src/3D/cube3D.ts:1)

Licensing posture:

- `GPL-3.0-or-later`
- the README now says the functionality moved into `cubing.js`, but this mirror still remains a separate restrictive custody lane
- Model B may only consume [cubing-twisty-js.model-a.md](C:/Workspaces/HyperTwist/clean-room-specs/cubing-twisty-js.model-a.md:1)

High-value salvage:

- `twisty.ts` shows a clean embedded surface: auto-initialized `<twisty>` elements, explicit `custom` initialization escape hatch, and attribute-to-config extraction
- the player shell is a clear composition of animation model, scrubber, control bar, and visualization views
- `anim.ts` contributes a real observer-driven playback core with cursor, direction, and jump dispatch rather than ad hoc callbacks
- `cursor.ts` is strong donor value because it turns expanded algorithm sequences into timestamped playback state, move fractions, and move-boundary stepping
- `puzzle.ts` contributes a compact abstract puzzle contract plus the `KPuzzle`-backed adapter boundary that keeps playback separate from any one concrete puzzle implementation
- `widget.ts` shows how to layer 2D SVG, 3D view, scrubber, control bar, and readout into a single embeddable player
- the 3D layer is narrower than a general renderer, but it still shows bounded camera/vantage management and `333`-specific animated cube presentation

Subordinate or later value:

- debug text views, HTML demo pages, and standalone packaging are not primary donor value
- the hardcoded `333` cube rendering path is useful as a clean-room reference surface, but not the main retained value compared with the player and cursor contracts
- the repository's deprecated standalone identity is context, not a reason to merge custody with other rows

Non-promotion decisions and rationale:

- do not treat this repo as a general runtime owner: `superseded by stronger retained donor`
- do not promote the exact `three.js` `333` rendering implementation into first-party core as-is: `implementation detail better reauthored first-party`
- do not flatten it into the broader `cubing/cubing.js` lane for governance purposes: `boundary discipline`
- do not elevate demo scaffolding and debug overlays into donor value: `host-shell glue`

Integration call:

- retain as the primary restrictive clean-room donor for compact embedded viewer/player behavior
- use it in `Phase 2R` to freeze element bootstrapping, observer-driven playback, scrubber/control semantics, and puzzle-adapter contracts
- refresh the Model A handoff with the deeper cursor, observer, and visualization-fallback findings
- if later implementation proceeds, schedule Model B work in `Phase 5R`, not as direct donor use
- current `2026-05-27` reconciliation overlay:
  - repo-local extraction unchanged
  - the first-party `HyperTwistSimulation` owner lane is now verified live and
    closed through `Bound 4`
  - keep classic-cubing semantics with `cubing/cubing.js`, parser and AST
    ownership with `cubing/alg.js`, and broader browser support ownership with
    the landed browser support lanes
  - do not reopen `Bound 1` through `Bound 4` by default; later work must be a
    new consumer-owner or shell packet if justified

### `HactarCE/2x2x2x2-Scrambler`

Inspected source surfaces:

- [README.md](C:/Workspaces/HyperTwist/mirrors/restrictive/HactarCE/2x2x2x2-Scrambler/README.md:1)
- [src/cljc/scrambler/puzzle/core.cljc](C:/Workspaces/HyperTwist/mirrors/restrictive/HactarCE/2x2x2x2-Scrambler/src/cljc/scrambler/puzzle/core.cljc:1)
- [src/cljc/scrambler/puzzle/moves.cljc](C:/Workspaces/HyperTwist/mirrors/restrictive/HactarCE/2x2x2x2-Scrambler/src/cljc/scrambler/puzzle/moves.cljc:1)
- [src/cljc/scrambler/puzzle/state_generator.cljc](C:/Workspaces/HyperTwist/mirrors/restrictive/HactarCE/2x2x2x2-Scrambler/src/cljc/scrambler/puzzle/state_generator.cljc:1)
- [src/cljc/scrambler/puzzle/permutation_utils.cljc](C:/Workspaces/HyperTwist/mirrors/restrictive/HactarCE/2x2x2x2-Scrambler/src/cljc/scrambler/puzzle/permutation_utils.cljc:1)
- [src/cljs/scrambler/ui/flat_view.cljs](C:/Workspaces/HyperTwist/mirrors/restrictive/HactarCE/2x2x2x2-Scrambler/src/cljs/scrambler/ui/flat_view.cljs:1)
- [src/cljs/scrambler/ui/main.cljs](C:/Workspaces/HyperTwist/mirrors/restrictive/HactarCE/2x2x2x2-Scrambler/src/cljs/scrambler/ui/main.cljs:1)

Licensing posture:

- `GPL-3.0`
- upstream source explicitly records a ported lineage from `pentaquark394` and says some algorithms and comments were copied nearly verbatim
- Model B may only consume [hactarce-2x2x2x2-scrambler.model-a.md](C:/Workspaces/HyperTwist/clean-room-specs/hactarce-2x2x2x2-scrambler.model-a.md:1)

High-value salvage:

- the solved-state representation is compact and real: piece-position vector plus per-piece orientation vectors
- `core.cljc` carries durable piece-string and sticker-color derivation semantics, not just random generation
- handedness and corner-twist semantics are first-class, which is the real reason this repo stays useful despite its narrow scope
- `state_generator.cljc` gives a full solvable-state pipeline: parity-preserving piece shuffle, random orientation shuffle, corner-twist repair, and handedness repair
- `moves.cljc` is strong donor value because moves are represented as transformed solved-state objects and then composed, inverted, and grouped into named move families
- `flat_view.cljs` provides a lightweight but informative front/back flat debug view with piece labels and sticker peeks

Subordinate or later value:

- the current button shell and placeholder `"Scramble goes here"` output are not the retained value
- the planned solver, serialization, and simulator ideas are roadmap hints rather than current strong donor surfaces
- the exact Clojure data shapes are not important beyond the behavioral contracts they imply

Non-promotion decisions and rationale:

- do not treat this row as a general hyper runtime donor: `off topic`
- do not preserve the exact copied-port algorithms, comments, or docstrings: `clean-room only`
- do not elevate the minimal web shell into a product pattern donor: `host-shell glue`
- do not widen this repo into a major trainer or viewer owner: `narrow retained micro-domain`

Integration call:

- retain as the primary restrictive clean-room donor for Melinda `2x2x2x2` state generation and solvability semantics
- use it in `Phase 2R` to freeze the state format, solvability rules, move-family behavior, and debug-view acceptance criteria
- refresh the Model A handoff with the fuller state, parity, and view findings
- if later implementation proceeds, schedule Model B work in `Phase 5R`, not as direct donor use
- current `2026-05-27` reconciliation overlay:
  - repo-local extraction unchanged
  - the first-party `HyperTwistCore` Melinda owner lane is now verified live
    and closed through `Bound 4`
  - the landed owner slice is narrow: state legality, move-family application,
    random-state generation, scramble-packet construction, and flat debug or
    teaching projection
  - keep broader higher-dimensional runtime ownership with adjacent live lanes
    and keep `magiccube4d` only as legacy reference context for this slice
  - do not reopen `Bound 1` through `Bound 4` by default; later work must be a
    new consumer-owner or widening packet if justified

### `kash/cubedesk`

Inspected source surfaces:

- [README.md](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/README.md:1)
- [LICENSE.md](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/LICENSE.md:1)
- [package.json](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/package.json:1)
- [schema.prisma](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/schema.prisma:1)
- [server/app.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/server/app.ts:1)
- [shared/solve.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/shared/solve.ts:1)
- [shared/integration.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/shared/integration.ts:1)
- [client/util/cubes/cube_types.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/client/util/cubes/cube_types.ts:1)
- [client/util/cubes/cube_scrambles.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/client/util/cubes/cube_scrambles.ts:1)
- [client/util/smart_scramble.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/client/util/smart_scramble.ts:1)
- [client/components/timer/Timer.tsx](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/client/components/timer/Timer.tsx:1)
- [client/components/timer/smart_cube/SmartCube.tsx](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/client/components/timer/smart_cube/SmartCube.tsx:1)
- [client/components/timer/smart_cube/visual/index.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/client/components/timer/smart_cube/visual/index.ts:1)
- [client/components/timer/smart_cube/visual/core/RubiksCube.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/client/components/timer/smart_cube/visual/core/RubiksCube.ts:1)
- [client/components/trainer/Trainer.tsx](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/client/components/trainer/Trainer.tsx:1)
- [client/components/trainer/util/init.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/client/components/trainer/util/init.ts:1)
- [client/db/trainer/query.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/client/db/trainer/query.ts:1)
- [client/db/solves/query.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/client/db/solves/query.ts:1)
- [client/components/solve_info/SolveInfo.tsx](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/client/components/solve_info/SolveInfo.tsx:1)
- [client/components/solve_info/util/solution.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/client/components/solve_info/util/solution.ts:1)
- [client/components/solve_info/stats_info/recognition_chart/RecognitionChart.tsx](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/client/components/solve_info/stats_info/recognition_chart/RecognitionChart.tsx:1)
- [client/components/solve_info/stats_info/ll_trainer/LLTrainer.tsx](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/client/components/solve_info/stats_info/ll_trainer/LLTrainer.tsx:1)
- [client/components/stats/Stats.tsx](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/client/components/stats/Stats.tsx:1)
- [server/resolvers/Stats.resolver.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/server/resolvers/Stats.resolver.ts:1)
- [server/resolvers/Leaderboards.resolver.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/server/resolvers/Leaderboards.resolver.ts:1)
- [server/match/init.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/server/match/init.ts:1)
- [server/match/util.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/server/match/util.ts:1)
- [server/match/update/standings.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/server/match/update/standings.ts:1)
- [server/match/pair/pair_logic.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/server/match/pair/pair_logic.ts:1)
- [server/match/pair/elo/elo_matching.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/server/match/pair/elo/elo_matching.ts:1)
- [server/match/match_types/head_to_head.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/server/match/match_types/head_to_head.ts:1)
- [server/match/match_types/elimination.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/server/match/match_types/elimination.ts:1)
- [server/util/solve/turns.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/server/util/solve/turns.ts:1)
- [server/util/solve/ll_states.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/server/util/solve/ll_states.ts:1)
- [server/util/pro.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/kash/cubedesk/server/util/pro.ts:1)

Licensing posture:

- `README.md` and `LICENSE.md` say `GPLv3-or-later`
- `package.json` says `CubeDesk, Inc. All Rights Reserved`
- direct donor use is blocked by the contradiction even before the broader GPL constraints are considered
- Model B may only consume [kash-cubedesk.model-a.md](C:/Workspaces/HyperTwist/clean-room-specs/kash-cubedesk.model-a.md:1)

High-value salvage:

- `schema.prisma` is major donor value because it makes solve, session, user, integration, notification, trainer, and match boundaries explicit rather than leaving them implicit in UI code
- `server/app.ts` shows a real service composition pattern for GraphQL, Prisma, uploads, webhooks, Redis, search, socket setup, and template initialization without pretending the whole app is one blob
- the timer lane is broader than a stopwatch: layout/focus-mode shell, multiple timing backends, scramble surfaces, timer modules, and modal-safe embedding
- the smart-cube lane is especially valuable: turn queueing, preflight scramble completion, automatic timer start after scramble completion, inspection-time capture, solved-state management, and synchronized visual playback
- the trainer lane is strong donor value because it combines deterministic seeded algorithm selection, hydrated local trainer DBs, favorites/customization, and timer-modal composition for drill sessions
- the solve/session/stats lane is a real product system, not just charts: solve sanitation, solve/session/training-session/game-session distinctions, recognition and execution panels, LL-case extraction, shareable solve detail, and filtered local DB queries
- the multiplayer lane is strong retained value: Redis-backed socket room topology, lobby pairing, widening ELO windows, standings updates, disconnect handling, and match-type abstraction
- the repo also preserves later-value surfaces for linked services, feature gating, notification preferences, and leaderboard publication patterns

Subordinate or later value:

- community shell, landing pages, merch/ads, legal pages, profile cosmetics, and general site chrome are not the retained center of gravity
- Stripe/Pro membership, Discord/WCA specifics, and broader account-management flows are later product-shell concerns, not core donor value
- generic GraphQL boilerplate, CSS system, and commodity common components are implementation scaffolding, not the main reason this row is retained
- many cube-type enumerations and classic speedcubing assumptions are useful context, but should not dictate HyperTwist's final hyper-focused domain model

Non-promotion decisions and rationale:

- do not attempt a whole-app clean-room clone of CubeDesk: `host-shell glue`, `off topic`, and `boundary cost exceeds naive use`
- do not pull billing, paid-feature, Discord-role, or WCA-account flows into the early HyperTwist core: `off topic`
- do not let CubeDesk displace `Hyperspeedcube`, `qbr`, or the already-retained permissive trainer donors for foundation ownership: `superseded by stronger retained donor`
- do not treat the contradictory package metadata as a paperwork nuisance: `license contradiction must remain explicit`
- do not promote marketing, admin, ads, or merch surfaces into donor value: `off topic`

Integration call:

- retain as the broad strategic clean-room donor for trainer-session coupling, solve/session/training-session/game-session boundaries, integrated smart-cube workflow composition, and multiplayer product-pattern extraction
- use it in `Phase 2R` to freeze product workflow, data-model, timer-backend, smart-cube, drill-session, solve-detail, stats, and match-logic contracts
- refresh the Model A handoff so later Model B work is selective subsystem implementation rather than an accidental whole-app recreation
- if later implementation proceeds, schedule only bounded subsystem Model B work in `Phase 5R`, not a full app-shell clean-room clone

## 2026-05-27 selective hierarchy clarification

Later timer-family and trainer-family comparison sharpens how this row should
be read.

This packet should now be interpreted as:

- `kash/cubedesk` is not the primary same-slice owner for the already landed
  first-party local timer subsystem
- `kash/cubedesk` is not the broader competitive timer, scramble-registry, or
  smart-device benchmark/oracle owner either
- `Aarav2709/KubeTimr` keeps the landed `R1/F2` local timer lifecycle, split
  capture/editing, session stats, persistence, and timer-scoped replay slice
- `cs0x7f/cstimer` keeps the broader restrictive `A1` benchmark/oracle slice
  for competitive timer maturity, scramble breadth, and smart-device breadth
- `kash/cubedesk` keeps the retained clean-room owner posture for
  trainer-session coupling, solve/session/training-session/game-session
  boundaries, integrated smart-cube workflow composition, and multiplayer /
  leaderboard product patterns

That later evidence does not reopen the valid repo-local extraction in this
packet.

It only narrows the exact cross-lane ownership wording for the retained
`CubeDesk` slices and the future clean-room implementation route.

## 2026-05-27 live-status backfill

Later repo-local reconciliation and clean-worktree validation also sharpen the
current live status of this row.

This packet should now also be read as:

- the restrictive `kash/cubedesk` lane is not merely a held candidate anymore
- bounded first-party clean-room implementation is already landed and closed
  through `Bound 5`
- the closed bounded slices are:
  - `Bound 1` trainer-session coupling above the existing timer substrate
  - `Bound 2` solve/session/training-session/game-session domain and
    analytics-panel surfaces
  - `Bound 3` integrated smart-device workflow composition and local
    persistence/sync/cache policy
  - `Bound 4` publication/leaderboard projection and entitlement gating
  - `Bound 5` local friendship/notification/challenge support
- later work must not reopen `Bound 1` through `Bound 5` by default
- any future reopening must be a narrower later bound or widening packet above
  the already closed owner sequence
