hypertwist/docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md

HyperTwist Canonical Restart Reconciliation

Created on 2026-05-12

Purpose

This document reconciles the current HyperTwist restart authority across the three canonical planning/governance locations that were parsed in this pass:

• C:\HyperTwist\docs
• C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse
• C:\Workspaces\HyperTwist

It exists to prevent future sessions from mixing:

• portfolio posture
• historical phase-lineage notes
• clean-room workflow precedent
• actual live implementation truth

It now also exists to prevent future sessions from collapsing:

• bookmarked
• queued
• source-read
• retained
• product-fit
• implementation-authorized
• implemented

into one vague repo judgment.

Scope of this reconciliation

This pass parsed the canonical docs, ledgers, prompts, clean-room notes, and workspace manifest that future sessions are most likely to treat as authority.

It was an authority-led end-to-end documentation parse.

It was not a line-by-line reread of every mirror, archive, zipped source copy, or generated output folder.

C:\HyperTwist\docs2 was requested as part of the canonical sweep, but that path did not exist at audit time.

Current handling:

• treat docs2 as absent
• do not assume it contains missing authority
• if it is created later, it must inherit the restart authority order defined here

Reconciled current truth

The current reconciled HyperTwist truth is:

• current curated HyperTwist shallow-eval set: 71 repos
• currently verified live in checked UnrealHyperTwist surfaces: 20
• currently verified live permissive lanes: 13
• currently verified live boundary-sensitive lanes: 6
• currently verified live restrictive lanes: 1

2026-06-12 routing correction:

• the 2026-05-12 snapshot above remains historically accurate for that restart pass
• preserve the already-landed first-party Phase 4R-F outputs
• for current work, do not treat remotion-dev/remotion as a default future boundary-sensitive widening lane; route future donor-backed widening through restrictive custody and explicit clean-room/specification work, or replace it with a first-party Unreal-native export path

The thirteen currently verified live permissive lanes are:

• Aarav2709/KubeTimr
• apache/echarts
• abunickabhi/5style-Trainer
• google/model-viewer
• Hypercubers/hypercubing.xyz
• mrdoob/three.js
• pmndrs/react-three-fiber
• pmndrs/xr
• tao-yu/Alg-Trainer
• Lykos/cube_trainer
• met4citizen/TalkingHead
• poliva/cubedex
• newyork-anthonyng/rubiks-cross-trainer

The six currently verified live boundary-sensitive lanes are:

• cubing/cubing.js
• cutelyaware/magiccube4d
• google/model-viewer/packages/shared-assets
• PostHog/posthog
• screenpipe/screenpipe
• remotion-dev/remotion

The one currently verified live restrictive lane is:

• onionhoney/roux-trainers

That restrictive lane must be treated as:

• properly clean-roomed
• properly implemented afterward
• preserved as the current clean-room precedent
• not to be reopened as an unresolved direct-donor contamination event

The remaining 51 rows are not to be treated as already implemented.

Phase 0R is now closed for that non-live set.

Those rows now resolve into:

• retained straight-permissive candidates
• retained boundary-sensitive candidates
• retained restrictive clean-room candidates
• retained benchmark, oracle, and clean-room-later rows
• discarded active-set rows

2026-05-14 intake and product-fit doctrine update

HyperTwist now treats the following as mandatory doctrine:

• a bookmarked repo is only intake
• a queued repo is only sequencing
• a source-read repo is only evidence gained
• a retained repo is only a repo that survived evaluation in some posture
• product-fit is a separate judgment from retention
• implementation-authorized is a separate judgment from product-fit
• implemented means landed in first-party product surfaces under explicit implementation authority

Canonical doctrine docs:

• docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md
• docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md

Operational implication:

• do not let bookmark presence, queue position, frequent mention, planning artifacts, or docs metadata masquerade as product intent or proof of implementation
• donor strength and legal posture are separate axes
• permissive status does not automatically win a lane
• restrictive or boundary-sensitive status does not automatically lose a lane
• harder route does not mean weaker donor
• routine live or product-surface scanning is no longer the default evaluation step
• assume a repo is not implemented unless explicit implementation authority says otherwise
• verify current implementation state only when the active task depends on that fact

Canonical-location findings

C:\HyperTwist\docs

The repo docs already carried the correct core implementation truth from 2026-05-11, but they still needed:

• explicit cross-location reconciliation
• explicit demotion of old parse-side Phase 4 continuation docs for restart work
• an explicit post-Phase 1R sequence instead of only a Phase 0R / Phase 1R stop point

C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse

The parse repo still contains essential governance material, especially:

• 06-project-agnostic-repo-evaluation-modus-operandi.md
• 07-benchmark-oracle-vs-clean-room-implementation.md
• 88-roadmap-implementation-workbook.md
• 89-phase-0-and-phase-1-bootstrap-packet.md

But several parse-side docs were stale as active restart authority:

• README.md still foregrounded the old 75-row canon and old authority chain
• 90-clean-room-safe-project-context.md still claimed Aarav2709/KubeTimr was already live and still framed the old active Phase 4 lane as current
• 96-hypertwist-live-execution-roadmap.md, 116-hypertwist-handoff.md, and 119-hypertwist-current-execution-reality-and-phase-discipline.md still framed the old bounded Phase 4 continuation lane as the active restart authority

Those docs remain useful lineage.

They are no longer the primary restart authority.

C:\Workspaces\HyperTwist

The workspace repo remains the external control-plane and clean-room handoff surface.

It needed correction because:

• the root README.md did not surface the current 71 / 9 / 8 / 1 truth
• clean-room notes still described onionhoney/roux-trainers as the current active next restrictive lane rather than the preserved already-landed restrictive precedent
• repos.manifest.json did not surface the Phase 0R reset and still contained a stale app handoff pointer

Restart authority order

For restart and future widening decisions, use this order:

1. docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md
2. docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md
3. docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md
4. docs/HT_REPO_INCORPORATION_AUDIT_2026-05-11.md
5. docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md
6. packet-level deep-source authority docs for any repo being implemented:
   • docs/HYPERTWIST_PHASE_0R_PACKET_0R_A_EVALUATION_2026-05-12.md
   • later Phase 0R packet docs as they are upgraded to the same standard
7. docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md
8. docs/REPO_LICENSE_TRACKING.md
9. docs/v6_5_deep_manual_pack/README.md
10. docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md
11. docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md
12. safe parse/workbook governance docs:

• 06-project-agnostic-repo-evaluation-modus-operandi.md
• 07-benchmark-oracle-vs-clean-room-implementation.md
• 88-roadmap-implementation-workbook.md
• 89-phase-0-and-phase-1-bootstrap-packet.md
• 90-clean-room-safe-project-context.md
• 122-hypertwist-phase-0r-restart-authority-and-sequencing.md

13. the current v6.3 CSV boards and prompts

Use the following only as lineage or historical context unless a restart doc explicitly points back to them:

• 96-hypertwist-live-execution-roadmap.md
• 116-hypertwist-handoff.md
• 119-hypertwist-current-execution-reality-and-phase-discipline.md

Restart doctrine

The restart is not a mass revert.

It is a provenance and planning reset around the remaining 51 current non-live rows while preserving the twenty already-landed lanes.

Required standing rules:

• preserve the twenty landed lanes
• preserve onionhoney/roux-trainers as the only currently verified landed restrictive clean-room lane
• do not collapse bookmarked, queued, source-read, retained, product-fit, implementation-authorized, and implemented
• do not collapse selected, retained, integrate, repurpose, or donor bench into already implemented
• do not widen new donor-shaped implementation from the remaining 51 current non-live rows until the closed packet sequence routes it
• before implementing any retained repo, read the packet-level deep-source authority doc for that repo class if one exists

2026-05-12 packet-depth correction

Packet 0R-A was originally closed correctly as a retained-set packet, but too shallowly.

Current correction:

• docs/HYPERTWIST_PHASE_0R_PACKET_0R_A_EVALUATION_2026-05-12.md is now the deep-source integration authority for the seven 0R-A repos
• it records what source was actually read, what value must be salvaged, and why any surface is not promoted
• future Phase 0R packets should use the same standard rather than only describing keep/discard posture

Practical implication:

• if a future instance is about to integrate Hyperspeedcube, qbr, rubix-cube-solver, KubeTimr, MagicTile, Magic120Cell, or MagicCube5D, it should not start from the shallow CSV row or bucket label
• it should start from 0R-A, then check REPO_LICENSE_TRACKING.md, then return to the schedule

Packet 0R-D required one more boundary rule because it covers restrictive clean-room rows.

Current correction:

• docs/HYPERTWIST_PHASE_0R_PACKET_0R_D_EVALUATION_2026-05-13.md is now the governance and Model A authority for the four restrictive retained rows
• it records what source was actually read, what value must be salvaged, what was not promoted, and why
• the repo-specific scrubbed files in C:\Workspaces\HyperTwist\clean-room-specs\ remain the only implementation-safe Model B handoff inputs

Practical implication:

• if a future instance is about to implement cubing/alg.js, cubing/twisty.js, HactarCE/2x2x2x2-Scrambler, or kash/cubedesk, it must read 0R-D, then REPO_LICENSE_TRACKING.md, then the repo-specific scrubbed Model A handoff
• it must not treat 0R-D itself as a substitute for the scrubbed handoff during Model B work

Restart phase sequence

Phase 0R — deep repo source integration evaluation

Goal:

• deeply evaluate the remaining 51 rows repo by repo

Required output per retained row:

• final license posture
• keep / promote / demote / benchmark / discard decision
• implementation lane:
  • straight permissive implementation
  • bounded dependency or adapter
  • restrictive clean-room
  • benchmark/oracle only
  • discard
• evidence links
• compliance notes
• scheduling wave

Exit gate:

• every remaining row has a ratified current-state decision

Phase 1R — contract and handoff overhaul

Goal:

• rebuild the implementation-facing contract layer from only:
  • the six already-landed lanes
  • the retained subset that survives Phase 0R

Required output:

• refreshed CSV boards
• refreshed license tracker
• refreshed roadmap and handoff docs
• refreshed clean-room inventory
• refreshed Model B allowlist and source-boundary docs

Exit gate:

• no retained row depends on stale pre-reset wording to describe its next action

Phase 2R — retained-set ratification and packet design

Goal:

• turn the retained post-Phase 0R set into an implementation-ready backlog

Required output:

• retained-set implementation board
• package ordering by subsystem
• ownership boundaries
• acceptance criteria for each retained lane

Exit gate:

• every retained lane has an implementation packet class and an explicit entry point into the roadmap

Phase 3R — permissive direct-implementation waves

Goal:

• execute the retained straight-permissive lanes first

Expected lane types:

• direct donor implementation
• bounded first-party adaptation
• permissive subsystem extraction

Exit gate:

• the high-value retained permissive rows that clearly shorten delivery are either landed or deliberately deferred

Phase 4R — boundary-sensitive dependency and sidecar waves

Goal:

• execute the retained mixed-term, attribution-heavy, sidecar, and adapter-heavy lanes

Expected lane types:

• MPL-side dependency or adapter use
• attribution-preserved donor use
• commercial or mixed-license bounded sidecars
• explicit enterprise-slice exclusion

Exit gate:

• every retained boundary-sensitive row has a closed consumption plan or a discard decision

Phase 5R — restrictive clean-room waves

Goal:

• execute retained restrictive lanes through refreshed Model A / Model B separation

Expected lane types:

• new restrictive clean-room implementations
• refreshed restrictive handoff dossiers
• fresh clean implementation packets using only approved safe artifacts

Exit gate:

• every retained restrictive lane is either:
  • landed through clean-room
  • still queued with a refreshed clean-room chain
  • or deliberately discarded

Phase 6R — simulation, recognition, XR, and support-plane widening

Goal:

• widen product capability only from the retained evaluated set

Expected focus:

• hyper/simulation widening
• recognition and reconstruction widening
• XR and presentation widening
• support-plane tooling that survives retention review

Exit gate:

• widening is traceable to retained rows rather than stale portfolio optimism

Phase 7R — benchmark, oracle, discard, and release-hardening closure

Goal:

• close the remaining oracle/reference/discard decisions and tie them to validation

Expected focus:

• benchmark harnesses
• solver/timer/reference comparisons
• discard memorialization
• compliance and notice closure
• release-hardening checks

Exit gate:

• no retained benchmark/reference row remains in ambiguous limbo

Recommended Phase 0R packet order

Start with the highest-value lanes that can change the retained-set shape fastest.

Packet 0R-A — permissive architecture anchors

Start here:

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

Why first:

• these rows are structurally important
• several can become direct implementation or bounded donor lanes without clean-room overhead
• they shape later simulation, recognition, timer, and hypercube planning

Packet 0R-B — remaining permissive product donors

Next:

• retained training, solver, analytics, curriculum, and browser-support rows such as:
  • cahidenes/rubiks-cube-solver
  • tentone/rubix-solver
  • Hypercubers/hypercubing.xyz
  • apache/echarts
  • ecomfe/zrender
  • ecomfe/echarts-gl
  • retained google/model-viewer and pmndrs/* support rows

Why next:

• they are likely to remain permissive implementation candidates
• they benefit from anchor decisions made in 0R-A

Packet 0R-C — boundary-sensitive retained rows

Then:

• cubing/cubing.js
• cutelyaware/magiccube4d
• google/model-viewer/packages/shared-assets
• PostHog/posthog
• remotion-dev/remotion
• screenpipe/screenpipe

Why here:

• these are not restrictive clean-room rows
• but they still need explicit adapter, notice, asset-term, enterprise-slice, or commercial-boundary decisions before implementation resumes

Packet 0R-D — restrictive clean-room re-selection

Then:

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

Why here:

• these are the restrictive lanes still selected but not yet verified live
• they need refreshed retention decisions before any new Model A / Model B work resumes

Packet 0R-E — reference, benchmark, reserve, and discard closure

Then:

• cs0x7f/cstimer
• brownan/Rubiks-Cube-Solver
• efrantar/rob-twophase
• ShellPuppy/RCube
• vwcwong/CubeSim
• MathewKJ2048/Rubiks-cube-simulator
• aMonteSl/CodeXR
• AviKaufman/Rubix-cube-trainer
• alinen/cube
• ambisinister/blindsolve
• brianpeiris/RiftSketch
• yakupbilen/drl-rubiks-cube

Why last:

• these rows are more likely to end as oracle, benchmark, reserve, or discard decisions than as near-term implementation packets

Documentation maintenance rule

After this reconciliation:

• new restart docs must say whether they are describing live implementation truth, portfolio posture, or historical lineage
• no canonical doc should use implemented, full, or already live for a repo unless current first-party evidence supports it
• no clean-room doc should describe onionhoney/roux-trainers as the next pending restrictive implementation lane without also saying it is already the landed restrictive clean-room precedent

Current packet status

Packet 0R-A, Packet 0R-B, Packet 0R-C, Packet 0R-D, Packet 0R-E, Phase 1R, the live-lane preservation audit, Phase 2R-A, Phase 2R-B, and Phase 2R-C are now closed as authority steps.

See:

• docs/HYPERTWIST_PHASE_0R_PACKET_0R_A_EVALUATION_2026-05-12.md
• docs/HYPERTWIST_PHASE_0R_PACKET_0R_B_EVALUATION_2026-05-12.md
• docs/HYPERTWIST_PHASE_0R_PACKET_0R_C_EVALUATION_2026-05-12.md
• docs/HYPERTWIST_PHASE_0R_PACKET_0R_D_EVALUATION_2026-05-13.md
• docs/HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md
• docs/HYPERTWIST_PHASE_1R_RETAINED_SET_CONTRACT_AND_HANDOFF_2026-05-13.md
• docs/HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md
• docs/HYPERTWIST_PHASE_2R_PACKET_2R_A_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md
• docs/HYPERTWIST_PHASE_2R_PACKET_2R_B_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md
• docs/HYPERTWIST_PHASE_2R_PACKET_2R_C_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md

Result:

• all seven 0R-A repos remain retained
• all thirty-six 0R-B repos remain retained
• all six 0R-C repos remain retained
• all four 0R-D repos remain retained
• 9 0R-E rows remain retained only as benchmark, oracle, or clean-room-later reservations
• 3 0R-E rows are now discarded from the active retained set
• Packet 0R-B is now a deep-source integration authority packet, not merely a permissive backlog summary
• Packet 0R-C is now the deep-source boundary-use authority for the mixed, attributed, asset-term, and commercial rows
• Packet 0R-D is now the governance and Model A authority for the restrictive clean-room rows
• Packet 0R-E is now the deep-source benchmark, reference, clean-room-later, and discard authority for its twelve rows
• Phase 1R is now the retained-set contract and handoff authority for all post-Phase 0R routing
• the eleven already-live rows now also have symmetric source-backed preservation authority through the live-lane audit
• Phase 2R-A is now the ownership and acceptance authority for the five core retained permissive rows
• Phase 2R-B is now the ownership and acceptance authority for the primary retained permissive support-plane rows in scope
• Phase 2R-C is now the ownership and acceptance authority for the final residual 0R-B permissive rows
• Phase 2R is now fully closed for the retained permissive set
• Phase 3R-A is now the landed implementation authority for Aarav2709/KubeTimr
• Phase 3R-B is now the landed implementation authority for Hypercubers/hypercubing.xyz
• Phase 3R-C is now the landed implementation authority for apache/echarts
• Phase 3R-D is now the landed implementation authority for google/model-viewer
• Aarav2709/KubeTimr is now the sixth permissive live lane and seventh live row overall
• Hypercubers/hypercubing.xyz is now the seventh permissive live lane and eighth live row overall
• apache/echarts is now the eighth permissive live lane and ninth live row overall
• google/model-viewer is now the ninth permissive live lane and tenth live row overall
• met4citizen/TalkingHead is now the tenth permissive live lane and eleventh live row overall
• mrdoob/three.js is now the eleventh permissive live lane and twelfth live row overall
• pmndrs/react-three-fiber is now the twelfth permissive live lane and thirteenth live row overall
• pmndrs/xr is now the thirteenth permissive live lane and fourteenth live row overall
• HactarCE/Hyperspeedcube, kkoomen/qbr, vivaansinghvi07/rubix-cube-solver, and roice3/MagicTile remain packetized for Phase 6R
• Hypercubers/hypercubing.xyz is now a landed permissive knowledge/curriculum/community lane rather than the next straight permissive candidate
• apache/echarts is now a landed permissive analytics/reporting lane rather than the next straight permissive candidate
• google/model-viewer plus KhronosGroup/glTF-Sample-Viewer are now the landed browser presentation/editor and standards-QA 3R-D lane
• met4citizen/TalkingHead is now the landed embodied companion 3R-E lane
• mrdoob/three.js, pmndrs/react-three-fiber, and pmndrs/xr are now the landed browser spatial owner trio through 3R-F
• cahidenes/rubiks-cube-solver and tentone/rubix-solver now form the retained recognition-comparison adjunct lane, not a currently open Phase 6R-* packet route
• NuiLab/code-vr now forms the retained 6R-F symbolic-to-spatial XR pedagogy experiment lane
• pissang/claygl and pissang/clay-viewer now form the retained optional 3R-G alternative browser comparison lane
• cubing/cubing.js is now the fifteenth live row overall and one live boundary-sensitive lane through the closed Phase 4R-A classic-cubing adapter packet
• cutelyaware/magiccube4d is now the sixteenth live row overall and the second live boundary-sensitive lane through the closed Phase 4R-B attributed legacy 4D adapter packet
• google/model-viewer/packages/shared-assets is now the seventeenth live row overall and the third live boundary-sensitive lane through the closed Phase 4R-C shared-assets allowlist packet
• PostHog/posthog is now the eighteenth live row overall and the fourth live boundary-sensitive lane through the closed Phase 4R-D control-plane packet
• screenpipe/screenpipe is now the nineteenth live row overall and the fifth live boundary-sensitive lane through the closed Phase 4R-E capture-history packet
• remotion-dev/remotion is now the twentieth live row overall and the sixth live boundary-sensitive lane through the closed Phase 4R-F media-export packet

License-tracking boundary:

• docs/REPO_LICENSE_TRACKING.md is the canonical repo-row legal and attribution ledger
• docs/v6_5_deep_manual_pack/HyperTwist/LICENSETRACKING.md is policy-only and must not become a second repo-row legal ledger
• docs/HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md is the source-backed preservation authority for the twenty already-live rows
• docs/HYPERTWIST_PHASE_2R_PACKET_2R_A_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md is the packet authority for the five core retained permissive rows once source extraction has already been read
• docs/HYPERTWIST_PHASE_2R_PACKET_2R_B_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md is the packet authority for the primary retained permissive support-plane rows once source extraction has already been read
• docs/HYPERTWIST_PHASE_2R_PACKET_2R_C_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md is the packet authority for the final residual permissive 0R-B adjunct and alternative-support rows once source extraction has already been read
• Packet 0R-A, Packet 0R-B, and Packet 0R-C are the source-value and exclusion-rationale authorities for their retained rows
• Packet 0R-D is the governance and Model A authority for its retained rows, but not the Model B handoff artifact
• Packet 0R-E is the source-value and discard-rationale authority for its twelve rows
• those packet docs must now also carry concise implementation-facing licensing snapshots so an integrating instance does not miss the legal posture at handoff time
• full license, attribution, notice, asset-term, and provenance obligations still belong in docs/REPO_LICENSE_TRACKING.md

Practical next move

The next bounded move is:

1. preserve the twenty landed rows as the current truth
2. keep Aarav2709/KubeTimr, Hypercubers/hypercubing.xyz, apache/echarts, google/model-viewer, met4citizen/TalkingHead, mrdoob/three.js, pmndrs/react-three-fiber, pmndrs/xr, cubing/cubing.js, cutelyaware/magiccube4d, google/model-viewer/packages/shared-assets, PostHog/posthog, screenpipe/screenpipe, and remotion-dev/remotion on preserve-and-enhance footing through their landed packets
3. open Phase 5R-A
4. widen cubing/alg.js as the first refreshed clean-room implementation lane from its scrubbed Model A dossier, while keeping the optional Phase 3R-G browser comparison lane deferred unless the landed primary browser spatial stack exposes a real gap