Bootstrap HyperTwist repo and CI
This commit is contained in:
axiomlogicnexus
commit
a05c9d85fe
72 changed files with 34164 additions and 0 deletions
2
.gitattributes
vendored
Normal file
2
.gitattributes
vendored
Normal file
|
|
@ -0,0 +1,2 @@
|
|||
# Auto detect text files and perform LF normalization
|
||||
* text=auto
|
||||
49
.gitignore
vendored
Normal file
49
.gitignore
vendored
Normal file
|
|
@ -0,0 +1,49 @@
|
|||
.vs/
|
||||
x64/
|
||||
mirrors/
|
||||
zippedreposource/
|
||||
__hyper_tokens.txt
|
||||
|
||||
# Sensitive or reference-only material.
|
||||
docs/refs/
|
||||
|
||||
# Local archive and mirror dumps.
|
||||
CubinApp.com/
|
||||
Hypercubing.xyz/
|
||||
MagicCube5D/
|
||||
Schläfli symbol/
|
||||
SpeedCubeDB/
|
||||
Superliminal Wiki/
|
||||
superliminal.com/
|
||||
logo/Miscellaneous/
|
||||
|
||||
# Root-level research/reference files not intended for the initial repo commit.
|
||||
Additional Notes on C#.txt
|
||||
Alghoritms Formula Trainer.pdf
|
||||
How-To Properly Clean-Room Reverse Engineer.txt
|
||||
HyperTwist NyxOS Mirror Reuse Findings.txt
|
||||
HyperTwist ScriptoriumAI Reuse Findings.txt
|
||||
Model A & B Clean-Room Implementation Prompts.txt
|
||||
gancube-2x2-tutorial.webp
|
||||
gancube-3x3x3-layer-by-layer-tutorial.pdf
|
||||
gancube-4x4-guide.webp
|
||||
gancube-5x5-guide.webp
|
||||
gancube-layer-by-layer-tutorial.pdf
|
||||
gancube-megaminx-tutorial.webp
|
||||
gancube-mirror-guide.webp
|
||||
gancube-pyraminx-guide.webp
|
||||
gancube-skewb-guide.webp
|
||||
HyperTwist.sln
|
||||
HyperTwist.vcxproj
|
||||
HyperTwist.vcxproj.filters
|
||||
HyperTwist.vcxproj.user
|
||||
|
||||
# Unreal generated and third-party project state.
|
||||
UnrealHyperTwist/.vs/
|
||||
UnrealHyperTwist/Binaries/
|
||||
UnrealHyperTwist/DerivedDataCache/
|
||||
UnrealHyperTwist/Intermediate/
|
||||
UnrealHyperTwist/Saved/
|
||||
UnrealHyperTwist/Plugins/
|
||||
UnrealHyperTwist/.vsconfig
|
||||
UnrealHyperTwist/UnrealHyperTwist.sln
|
||||
30
.woodpecker/hypertwist-bootstrap.yml
Normal file
30
.woodpecker/hypertwist-bootstrap.yml
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
labels:
|
||||
role: builder
|
||||
backend: local
|
||||
|
||||
skip_clone: true
|
||||
|
||||
steps:
|
||||
checkout:
|
||||
image: powershell
|
||||
commands:
|
||||
- if (-not $env:CI_REPO_CLONE_URL) { throw 'CI_REPO_CLONE_URL missing; set the Forgejo-backed clone URL in Woodpecker.' }
|
||||
- $repoRoot = Join-Path (Get-Location).Path 'repo'
|
||||
- if (Test-Path $repoRoot) { Remove-Item -Recurse -Force $repoRoot }
|
||||
- git clone --branch main --single-branch $env:CI_REPO_CLONE_URL $repoRoot
|
||||
- Set-Location $repoRoot
|
||||
- if ($env:CI_COMMIT_SHA) { git checkout --detach $env:CI_COMMIT_SHA }
|
||||
|
||||
repo_sanity:
|
||||
image: powershell
|
||||
depends_on:
|
||||
- checkout
|
||||
commands:
|
||||
- Set-Location repo
|
||||
- git rev-parse --is-inside-work-tree
|
||||
- if (-not (Test-Path 'UnrealHyperTwist/UnrealHyperTwist.uproject')) { throw 'Missing UnrealHyperTwist/UnrealHyperTwist.uproject' }
|
||||
- if (-not (Test-Path 'UnrealHyperTwist/Source/UnrealHyperTwist')) { throw 'Missing UnrealHyperTwist source module root' }
|
||||
- if (-not (Test-Path 'docs')) { throw 'Missing docs directory' }
|
||||
- Get-ChildItem 'UnrealHyperTwist/Source/UnrealHyperTwist/Public' -Recurse | Select-Object -First 20 FullName
|
||||
when:
|
||||
- event: [push, pull_request, manual, tag]
|
||||
0
UnrealHyperTwist/Config/DefaultEditor.ini
Normal file
0
UnrealHyperTwist/Config/DefaultEditor.ini
Normal file
106
UnrealHyperTwist/Config/DefaultEngine.ini
Normal file
106
UnrealHyperTwist/Config/DefaultEngine.ini
Normal file
|
|
@ -0,0 +1,106 @@
|
|||
|
||||
|
||||
[/Script/EngineSettings.GameMapsSettings]
|
||||
GameDefaultMap=/Engine/Maps/Templates/OpenWorld
|
||||
|
||||
[/Script/Engine.RendererSettings]
|
||||
r.AllowStaticLighting=False
|
||||
|
||||
r.GenerateMeshDistanceFields=True
|
||||
|
||||
r.DynamicGlobalIlluminationMethod=1
|
||||
|
||||
r.ReflectionMethod=1
|
||||
|
||||
r.SkinCache.CompileShaders=True
|
||||
|
||||
r.RayTracing=True
|
||||
|
||||
r.RayTracing.RayTracingProxies.ProjectEnabled=True
|
||||
|
||||
r.Substrate=True
|
||||
|
||||
r.Substrate.ProjectGBufferFormat=0
|
||||
|
||||
r.Shadow.Virtual.Enable=1
|
||||
|
||||
r.DefaultFeature.AutoExposure.ExtendDefaultLuminanceRange=True
|
||||
|
||||
r.DefaultFeature.LocalExposure.HighlightContrastScale=0.8
|
||||
|
||||
r.DefaultFeature.LocalExposure.ShadowContrastScale=0.8
|
||||
|
||||
[/Script/WindowsTargetPlatform.WindowsTargetSettings]
|
||||
DefaultGraphicsRHI=DefaultGraphicsRHI_DX12
|
||||
DefaultGraphicsRHI=DefaultGraphicsRHI_DX12
|
||||
-D3D12TargetedShaderFormats=PCD3D_SM5
|
||||
+D3D12TargetedShaderFormats=PCD3D_SM6
|
||||
-D3D11TargetedShaderFormats=PCD3D_SM5
|
||||
+D3D11TargetedShaderFormats=PCD3D_SM5
|
||||
Compiler=Default
|
||||
AudioSampleRate=48000
|
||||
AudioCallbackBufferFrameSize=1024
|
||||
AudioNumBuffersToEnqueue=1
|
||||
AudioMaxChannels=0
|
||||
AudioNumSourceWorkers=4
|
||||
SpatializationPlugin=
|
||||
SourceDataOverridePlugin=
|
||||
ReverbPlugin=
|
||||
OcclusionPlugin=
|
||||
CompressionOverrides=(bOverrideCompressionTimes=False,DurationThreshold=5.000000,MaxNumRandomBranches=0,SoundCueQualityIndex=0)
|
||||
CacheSizeKB=65536
|
||||
MaxChunkSizeOverrideKB=0
|
||||
bResampleForDevice=False
|
||||
MaxSampleRate=48000.000000
|
||||
HighSampleRate=32000.000000
|
||||
MedSampleRate=24000.000000
|
||||
LowSampleRate=12000.000000
|
||||
MinSampleRate=8000.000000
|
||||
CompressionQualityModifier=1.000000
|
||||
AutoStreamingThreshold=0.000000
|
||||
SoundCueCookQualityIndex=-1
|
||||
|
||||
[/Script/LinuxTargetPlatform.LinuxTargetSettings]
|
||||
-TargetedRHIs=SF_VULKAN_SM5
|
||||
+TargetedRHIs=SF_VULKAN_SM6
|
||||
|
||||
[/Script/MacTargetPlatform.MacTargetSettings]
|
||||
-TargetedRHIs=SF_METAL_SM5
|
||||
+TargetedRHIs=SF_METAL_SM6
|
||||
|
||||
[/Script/HardwareTargeting.HardwareTargetingSettings]
|
||||
TargetedHardwareClass=Desktop
|
||||
AppliedTargetedHardwareClass=Desktop
|
||||
DefaultGraphicsPerformance=Maximum
|
||||
AppliedDefaultGraphicsPerformance=Maximum
|
||||
|
||||
[/Script/WorldPartitionEditor.WorldPartitionEditorSettings]
|
||||
CommandletClass=Class'/Script/UnrealEd.WorldPartitionConvertCommandlet'
|
||||
|
||||
[/Script/Engine.UserInterfaceSettings]
|
||||
bAuthorizeAutomaticWidgetVariableCreation=False
|
||||
FontDPIPreset=Standard
|
||||
FontDPI=72
|
||||
|
||||
[/Script/Engine.Engine]
|
||||
+ActiveGameNameRedirects=(OldGameName="TP_Blank",NewGameName="/Script/UnrealHyperTwist")
|
||||
+ActiveGameNameRedirects=(OldGameName="/Script/TP_Blank",NewGameName="/Script/UnrealHyperTwist")
|
||||
|
||||
[/Script/AndroidFileServerEditor.AndroidFileServerRuntimeSettings]
|
||||
bEnablePlugin=True
|
||||
bAllowNetworkConnection=True
|
||||
SecurityToken=3FF5C1E845BC1709E14ADEB4DD4950E5
|
||||
bIncludeInShipping=False
|
||||
bAllowExternalStartInShipping=False
|
||||
bCompileAFSProject=False
|
||||
bUseCompression=False
|
||||
bLogFiles=False
|
||||
bReportStats=False
|
||||
ConnectionType=USBOnly
|
||||
bUseManualIPAddress=False
|
||||
ManualIPAddress=
|
||||
|
||||
[/Script/PythonScriptPlugin.PythonScriptPluginSettings]
|
||||
bRemoteExecution=True
|
||||
bDeveloperMode=True
|
||||
|
||||
6
UnrealHyperTwist/Config/DefaultGame.ini
Normal file
6
UnrealHyperTwist/Config/DefaultGame.ini
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
|
||||
[/Script/CommonUI.CommonUISettings]
|
||||
CommonButtonAcceptKeyHandling=TriggerClick
|
||||
|
||||
[/Script/EngineSettings.GeneralProjectSettings]
|
||||
ProjectID=11C9116142A58F76A4E7F987AE989538
|
||||
84
UnrealHyperTwist/Config/DefaultInput.ini
Normal file
84
UnrealHyperTwist/Config/DefaultInput.ini
Normal file
|
|
@ -0,0 +1,84 @@
|
|||
[/Script/Engine.InputSettings]
|
||||
-AxisConfig=(AxisKeyName="Gamepad_LeftX",AxisProperties=(DeadZone=0.25,Exponent=1.f,Sensitivity=1.f))
|
||||
-AxisConfig=(AxisKeyName="Gamepad_LeftY",AxisProperties=(DeadZone=0.25,Exponent=1.f,Sensitivity=1.f))
|
||||
-AxisConfig=(AxisKeyName="Gamepad_RightX",AxisProperties=(DeadZone=0.25,Exponent=1.f,Sensitivity=1.f))
|
||||
-AxisConfig=(AxisKeyName="Gamepad_RightY",AxisProperties=(DeadZone=0.25,Exponent=1.f,Sensitivity=1.f))
|
||||
-AxisConfig=(AxisKeyName="MouseX",AxisProperties=(DeadZone=0.f,Exponent=1.f,Sensitivity=0.07f))
|
||||
-AxisConfig=(AxisKeyName="MouseY",AxisProperties=(DeadZone=0.f,Exponent=1.f,Sensitivity=0.07f))
|
||||
-AxisConfig=(AxisKeyName="Mouse2D",AxisProperties=(DeadZone=0.f,Exponent=1.f,Sensitivity=0.07f))
|
||||
+AxisConfig=(AxisKeyName="Gamepad_LeftX",AxisProperties=(DeadZone=0.250000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="Gamepad_LeftY",AxisProperties=(DeadZone=0.250000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="Gamepad_RightX",AxisProperties=(DeadZone=0.250000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="Gamepad_RightY",AxisProperties=(DeadZone=0.250000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="MouseX",AxisProperties=(DeadZone=0.000000,Sensitivity=0.070000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="MouseY",AxisProperties=(DeadZone=0.000000,Sensitivity=0.070000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="Mouse2D",AxisProperties=(DeadZone=0.000000,Sensitivity=0.070000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="MouseWheelAxis",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="Gamepad_LeftTriggerAxis",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="Gamepad_RightTriggerAxis",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="Gamepad_Special_Left_X",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="Gamepad_Special_Left_Y",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="Vive_Left_Trigger_Axis",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="Vive_Left_Trackpad_X",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="Vive_Left_Trackpad_Y",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="Vive_Right_Trigger_Axis",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="Vive_Right_Trackpad_X",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="Vive_Right_Trackpad_Y",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="MixedReality_Left_Trigger_Axis",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="MixedReality_Left_Thumbstick_X",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="MixedReality_Left_Thumbstick_Y",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="MixedReality_Left_Trackpad_X",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="MixedReality_Left_Trackpad_Y",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="MixedReality_Right_Trigger_Axis",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="MixedReality_Right_Thumbstick_X",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="MixedReality_Right_Thumbstick_Y",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="MixedReality_Right_Trackpad_X",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="MixedReality_Right_Trackpad_Y",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="OculusTouch_Left_Grip_Axis",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="OculusTouch_Left_Trigger_Axis",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="OculusTouch_Left_Thumbstick_X",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="OculusTouch_Left_Thumbstick_Y",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="OculusTouch_Right_Grip_Axis",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="OculusTouch_Right_Trigger_Axis",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="OculusTouch_Right_Thumbstick_X",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="OculusTouch_Right_Thumbstick_Y",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="ValveIndex_Left_Grip_Axis",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="ValveIndex_Left_Grip_Force",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="ValveIndex_Left_Trigger_Axis",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="ValveIndex_Left_Thumbstick_X",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="ValveIndex_Left_Thumbstick_Y",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="ValveIndex_Left_Trackpad_X",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="ValveIndex_Left_Trackpad_Y",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="ValveIndex_Left_Trackpad_Force",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="ValveIndex_Right_Grip_Axis",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="ValveIndex_Right_Grip_Force",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="ValveIndex_Right_Trigger_Axis",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="ValveIndex_Right_Thumbstick_X",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="ValveIndex_Right_Thumbstick_Y",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="ValveIndex_Right_Trackpad_X",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="ValveIndex_Right_Trackpad_Y",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
+AxisConfig=(AxisKeyName="ValveIndex_Right_Trackpad_Force",AxisProperties=(DeadZone=0.000000,Sensitivity=1.000000,Exponent=1.000000,bInvert=False))
|
||||
bAltEnterTogglesFullscreen=True
|
||||
bF11TogglesFullscreen=True
|
||||
bUseMouseForTouch=False
|
||||
bEnableMouseSmoothing=True
|
||||
bEnableFOVScaling=True
|
||||
bCaptureMouseOnLaunch=True
|
||||
bEnableLegacyInputScales=True
|
||||
bEnableMotionControls=True
|
||||
bFilterInputByPlatformUser=False
|
||||
bShouldFlushPressedKeysOnViewportFocusLost=True
|
||||
bAlwaysShowTouchInterface=False
|
||||
bShowConsoleOnFourFingerTap=True
|
||||
bEnableGestureRecognizer=False
|
||||
bUseAutocorrect=False
|
||||
DefaultViewportMouseCaptureMode=CapturePermanently_IncludingInitialMouseDown
|
||||
DefaultViewportMouseLockMode=LockOnCapture
|
||||
FOVScale=0.011110
|
||||
DoubleClickTime=0.200000
|
||||
DefaultPlayerInputClass=/Script/EnhancedInput.EnhancedPlayerInput
|
||||
DefaultInputComponentClass=/Script/EnhancedInput.EnhancedInputComponent
|
||||
DefaultTouchInterface=/Engine/MobileResources/HUD/DefaultVirtualJoysticks.DefaultVirtualJoysticks
|
||||
-ConsoleKeys=Tilde
|
||||
+ConsoleKeys=Tilde
|
||||
|
||||
15
UnrealHyperTwist/Source/UnrealHyperTwist.Target.cs
Normal file
15
UnrealHyperTwist/Source/UnrealHyperTwist.Target.cs
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
// Copyright Epic Games, Inc. All Rights Reserved.
|
||||
|
||||
using UnrealBuildTool;
|
||||
using System.Collections.Generic;
|
||||
|
||||
public class UnrealHyperTwistTarget : TargetRules
|
||||
{
|
||||
public UnrealHyperTwistTarget(TargetInfo Target) : base(Target)
|
||||
{
|
||||
Type = TargetType.Game;
|
||||
DefaultBuildSettings = BuildSettingsVersion.V6;
|
||||
IncludeOrderVersion = EngineIncludeOrderVersion.Unreal5_7;
|
||||
ExtraModuleNames.Add("UnrealHyperTwist");
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,325 @@
|
|||
#include "HyperTwistBootstrap/HyperTwistContractLibrary.h"
|
||||
|
||||
#include "JsonObjectConverter.h"
|
||||
|
||||
namespace HyperTwistContractLibraryInternal
|
||||
{
|
||||
template <typename TStruct>
|
||||
FString SerializeStructToJson(const TStruct& Value)
|
||||
{
|
||||
FString Json;
|
||||
FJsonObjectConverter::UStructToJsonObjectString(TStruct::StaticStruct(), &Value, Json, 0, 0);
|
||||
return Json;
|
||||
}
|
||||
|
||||
template <typename TStruct>
|
||||
bool DeserializeStructFromJson(const FString& Json, TStruct& OutValue)
|
||||
{
|
||||
return FJsonObjectConverter::JsonObjectStringToUStruct(Json, &OutValue, 0, 0);
|
||||
}
|
||||
}
|
||||
|
||||
FHyperTwistPuzzleDefinitionRef UHyperTwistContractLibrary::MakeSampleClassicPuzzleDefinition()
|
||||
{
|
||||
FHyperTwistPuzzleDefinitionRef Definition;
|
||||
Definition.PuzzleId = TEXT("cube/3x3x3");
|
||||
Definition.PuzzleFamily = EHyperTwistPuzzleFamily::ClassicCube;
|
||||
Definition.Dimension = 3;
|
||||
Definition.DefinitionVersion = TEXT("2026.04");
|
||||
Definition.NotationProfile = TEXT("classic-wca");
|
||||
Definition.SizeVector = {3, 3, 3};
|
||||
return Definition;
|
||||
}
|
||||
|
||||
FHyperTwistPuzzleDefinitionRef UHyperTwistContractLibrary::MakeSampleHyperPuzzleDefinition()
|
||||
{
|
||||
FHyperTwistPuzzleDefinitionRef Definition;
|
||||
Definition.PuzzleId = TEXT("hypercube/2x2x2x2");
|
||||
Definition.PuzzleFamily = EHyperTwistPuzzleFamily::Hypercube;
|
||||
Definition.Dimension = 4;
|
||||
Definition.DefinitionVersion = TEXT("2026.04");
|
||||
Definition.NotationProfile = TEXT("hyper-4d");
|
||||
Definition.SizeVector = {2, 2, 2, 2};
|
||||
return Definition;
|
||||
}
|
||||
|
||||
FHyperTwistPuzzleState UHyperTwistContractLibrary::MakeSampleClassicPuzzleState()
|
||||
{
|
||||
FHyperTwistClassicPieceOrbitState OrbitState;
|
||||
OrbitState.Corners.Permutation = {0, 1, 2, 3, 4, 5, 6, 7};
|
||||
OrbitState.Corners.Orientation = {0, 0, 0, 0, 0, 0, 0, 0};
|
||||
OrbitState.Edges.Permutation = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11};
|
||||
OrbitState.Edges.Orientation = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
|
||||
OrbitState.Centers.Permutation = {0, 1, 2, 3, 4, 5};
|
||||
OrbitState.Centers.Orientation = {0, 0, 0, 0, 0, 0};
|
||||
|
||||
FHyperTwistPuzzleState State;
|
||||
State.Definition = MakeSampleClassicPuzzleDefinition();
|
||||
State.StateEncodingKind = EHyperTwistStateEncodingKind::PieceOrbit;
|
||||
State.StateEncoding.EncodingProfile = OrbitState.EncodingProfile;
|
||||
State.StateEncoding.PayloadJson = HyperTwistContractLibraryInternal::SerializeStructToJson(OrbitState);
|
||||
State.OrientationFrame.Reference = TEXT("canonical-default");
|
||||
State.bIsSolved = true;
|
||||
State.Source = EHyperTwistStateSource::Runtime;
|
||||
State.CapturedAtUtc = TEXT("2026-04-25T12:00:00Z");
|
||||
State.SourceConfidence = -1.0f;
|
||||
return State;
|
||||
}
|
||||
|
||||
FHyperTwistPuzzleState UHyperTwistContractLibrary::MakeSampleClassicRecognitionPreviewState()
|
||||
{
|
||||
FHyperTwistClassicFaceletSnapshotState FaceletState;
|
||||
FaceletState.U = {TEXT("W"), TEXT("W"), TEXT("W"), TEXT("W"), TEXT("W"), TEXT("W"), TEXT("W"), TEXT("W"), TEXT("W")};
|
||||
FaceletState.R = {TEXT("R"), TEXT("R"), TEXT("R"), TEXT("R"), TEXT("R"), TEXT("R"), TEXT("R"), TEXT("R"), TEXT("R")};
|
||||
FaceletState.F = {TEXT("G"), TEXT("G"), TEXT("G"), TEXT("G"), TEXT("G"), TEXT("G"), TEXT("G"), TEXT("G"), TEXT("G")};
|
||||
FaceletState.D = {TEXT("Y"), TEXT("Y"), TEXT("Y"), TEXT("Y"), TEXT("Y"), TEXT("Y"), TEXT("Y"), TEXT("Y"), TEXT("Y")};
|
||||
FaceletState.L = {TEXT("O"), TEXT("O"), TEXT("O"), TEXT("O"), TEXT("O"), TEXT("O"), TEXT("O"), TEXT("O"), TEXT("O")};
|
||||
FaceletState.B = {TEXT("B"), TEXT("B"), TEXT("B"), TEXT("B"), TEXT("B"), TEXT("B"), TEXT("B"), TEXT("B"), TEXT("B")};
|
||||
|
||||
FHyperTwistPuzzleState State;
|
||||
State.Definition = MakeSampleClassicPuzzleDefinition();
|
||||
State.StateEncodingKind = EHyperTwistStateEncodingKind::Facelet;
|
||||
State.StateEncoding.EncodingProfile = FaceletState.EncodingProfile;
|
||||
State.StateEncoding.PayloadJson = HyperTwistContractLibraryInternal::SerializeStructToJson(FaceletState);
|
||||
State.OrientationFrame.Reference = TEXT("camera-relative");
|
||||
State.bIsSolved = false;
|
||||
State.Source = EHyperTwistStateSource::Recognition;
|
||||
State.CapturedAtUtc = TEXT("2026-04-25T12:00:00Z");
|
||||
State.SourceConfidence = 0.84f;
|
||||
State.SourceSessionId = TEXT("vision_01");
|
||||
return State;
|
||||
}
|
||||
|
||||
FHyperTwistPuzzleState UHyperTwistContractLibrary::MakeSampleHyperPuzzleState()
|
||||
{
|
||||
FHyperTwistHypercubePieceMapState HyperState;
|
||||
HyperState.Corners = {TEXT("c0"), TEXT("c1"), TEXT("c2"), TEXT("c3")};
|
||||
HyperState.Edges = {TEXT("e0"), TEXT("e1"), TEXT("e2"), TEXT("e3")};
|
||||
HyperState.Faces = {TEXT("f0"), TEXT("f1"), TEXT("f2"), TEXT("f3")};
|
||||
HyperState.Cells = {TEXT("cell0"), TEXT("cell1"), TEXT("cell2"), TEXT("cell3")};
|
||||
|
||||
FHyperTwistPuzzleState State;
|
||||
State.Definition = MakeSampleHyperPuzzleDefinition();
|
||||
State.StateEncodingKind = EHyperTwistStateEncodingKind::FamilySpecific;
|
||||
State.StateEncoding.EncodingProfile = HyperState.EncodingProfile;
|
||||
State.StateEncoding.PayloadJson = HyperTwistContractLibraryInternal::SerializeStructToJson(HyperState);
|
||||
State.OrientationFrame.Reference = TEXT("hypercube-canonical-v1");
|
||||
State.bIsSolved = true;
|
||||
State.Source = EHyperTwistStateSource::Runtime;
|
||||
State.CapturedAtUtc = TEXT("2026-04-25T12:00:00Z");
|
||||
return State;
|
||||
}
|
||||
|
||||
FHyperTwistTransformation UHyperTwistContractLibrary::MakeSampleClassicTransformation()
|
||||
{
|
||||
FHyperTwistClassicTransformEncoding TransformEncoding;
|
||||
TransformEncoding.MoveSequence = {TEXT("R"), TEXT("U"), TEXT("R'"), TEXT("U'")};
|
||||
|
||||
FHyperTwistTransformation Transformation;
|
||||
Transformation.Definition = MakeSampleClassicPuzzleDefinition();
|
||||
Transformation.TransformKind = EHyperTwistTransformKind::Algorithm;
|
||||
Transformation.Notation = TEXT("R U R' U'");
|
||||
Transformation.TransformEncoding.EncodingProfile = TransformEncoding.EncodingProfile;
|
||||
Transformation.TransformEncoding.PayloadJson = HyperTwistContractLibraryInternal::SerializeStructToJson(TransformEncoding);
|
||||
Transformation.OriginalNotation = Transformation.Notation;
|
||||
return Transformation;
|
||||
}
|
||||
|
||||
FHyperTwistReplayPacket UHyperTwistContractLibrary::MakeSampleRuntimeReplayPacket()
|
||||
{
|
||||
FHyperTwistReplayPhaseMarkPayload PhasePayload;
|
||||
PhasePayload.PhaseId = TEXT("phase_exec");
|
||||
PhasePayload.PhaseKind = TEXT("execution");
|
||||
PhasePayload.PhaseSource = TEXT("explicit");
|
||||
PhasePayload.PhaseAction = TEXT("start");
|
||||
|
||||
FHyperTwistReplayMovePayload MovePayload;
|
||||
MovePayload.Notation = TEXT("R");
|
||||
MovePayload.Source = TEXT("runtime");
|
||||
|
||||
FHyperTwistReplayEvent TimerStartEvent;
|
||||
TimerStartEvent.EventId = TEXT("evt_01");
|
||||
TimerStartEvent.Sequence = 1;
|
||||
TimerStartEvent.TimeMs = 0;
|
||||
TimerStartEvent.EventType = EHyperTwistReplayEventType::TimerStart;
|
||||
|
||||
FHyperTwistReplayEvent PhaseEvent;
|
||||
PhaseEvent.EventId = TEXT("evt_02");
|
||||
PhaseEvent.Sequence = 2;
|
||||
PhaseEvent.TimeMs = 100;
|
||||
PhaseEvent.EventType = EHyperTwistReplayEventType::PhaseMark;
|
||||
PhaseEvent.PayloadJson = HyperTwistContractLibraryInternal::SerializeStructToJson(PhasePayload);
|
||||
|
||||
FHyperTwistReplayEvent MoveEvent;
|
||||
MoveEvent.EventId = TEXT("evt_03");
|
||||
MoveEvent.Sequence = 3;
|
||||
MoveEvent.TimeMs = 250;
|
||||
MoveEvent.EventType = EHyperTwistReplayEventType::Move;
|
||||
MoveEvent.PayloadJson = HyperTwistContractLibraryInternal::SerializeStructToJson(MovePayload);
|
||||
|
||||
FHyperTwistPhaseTiming ExecutionTiming;
|
||||
ExecutionTiming.PhaseKind = TEXT("execution");
|
||||
ExecutionTiming.StartedAtMs = 100;
|
||||
ExecutionTiming.EndedAtMs = 12450;
|
||||
ExecutionTiming.DurationMs = 12350;
|
||||
|
||||
FHyperTwistReplayPacket Packet;
|
||||
Packet.ReplayId = TEXT("replay_runtime_01");
|
||||
Packet.PuzzleDefinition = MakeSampleClassicPuzzleDefinition();
|
||||
Packet.CaptureMode = EHyperTwistCaptureMode::Runtime;
|
||||
Packet.SessionId = TEXT("session_runtime_01");
|
||||
Packet.StartedAtUtc = TEXT("2026-04-25T12:00:00Z");
|
||||
Packet.EndedAtUtc = TEXT("2026-04-25T12:00:12Z");
|
||||
Packet.Events = {TimerStartEvent, PhaseEvent, MoveEvent};
|
||||
Packet.DerivedSummary.TotalTimeMs = 12450;
|
||||
Packet.DerivedSummary.MoveCount = 56;
|
||||
Packet.DerivedSummary.TPS = 4.93f;
|
||||
Packet.DerivedSummary.PhaseTimings = {ExecutionTiming};
|
||||
Packet.DerivedSummary.Result = TEXT("completed");
|
||||
return Packet;
|
||||
}
|
||||
|
||||
FHyperTwistReplayPacket UHyperTwistContractLibrary::MakeSampleRecognitionReplayPacket()
|
||||
{
|
||||
FHyperTwistReplayRecognitionPayload PreviewPayload;
|
||||
PreviewPayload.Snapshot.SnapshotId = TEXT("snap_preview");
|
||||
PreviewPayload.Snapshot.State = MakeSampleClassicRecognitionPreviewState();
|
||||
PreviewPayload.Snapshot.DerivedHash = TEXT("preview_hash");
|
||||
PreviewPayload.Confidence = 0.78f;
|
||||
PreviewPayload.ScanStage = TEXT("preview");
|
||||
|
||||
FHyperTwistReplayRecognitionPayload CommitPayload;
|
||||
CommitPayload.Snapshot.SnapshotId = TEXT("snap_commit");
|
||||
CommitPayload.Snapshot.State = MakeSampleClassicPuzzleState();
|
||||
CommitPayload.Snapshot.State.Source = EHyperTwistStateSource::Recognition;
|
||||
CommitPayload.Snapshot.State.SourceConfidence = 0.96f;
|
||||
CommitPayload.Snapshot.State.SourceSessionId = TEXT("vision_01");
|
||||
CommitPayload.Snapshot.DerivedHash = TEXT("commit_hash");
|
||||
CommitPayload.Confidence = 0.96f;
|
||||
CommitPayload.CommittedFaceOrStage = TEXT("F");
|
||||
CommitPayload.ScanStage = TEXT("commit");
|
||||
|
||||
FHyperTwistReplayEvent PreviewEvent;
|
||||
PreviewEvent.EventId = TEXT("evt_01");
|
||||
PreviewEvent.Sequence = 1;
|
||||
PreviewEvent.TimeMs = 0;
|
||||
PreviewEvent.EventType = EHyperTwistReplayEventType::RecognitionPreview;
|
||||
PreviewEvent.PayloadJson = HyperTwistContractLibraryInternal::SerializeStructToJson(PreviewPayload);
|
||||
|
||||
FHyperTwistReplayEvent CommitEvent;
|
||||
CommitEvent.EventId = TEXT("evt_02");
|
||||
CommitEvent.Sequence = 2;
|
||||
CommitEvent.TimeMs = 420;
|
||||
CommitEvent.EventType = EHyperTwistReplayEventType::RecognitionCommit;
|
||||
CommitEvent.PayloadJson = HyperTwistContractLibraryInternal::SerializeStructToJson(CommitPayload);
|
||||
|
||||
FHyperTwistReplayPacket Packet;
|
||||
Packet.ReplayId = TEXT("replay_vision_01");
|
||||
Packet.PuzzleDefinition = MakeSampleClassicPuzzleDefinition();
|
||||
Packet.CaptureMode = EHyperTwistCaptureMode::Recognition;
|
||||
Packet.SessionId = TEXT("vision_01");
|
||||
Packet.StartedAtUtc = TEXT("2026-04-25T12:00:00Z");
|
||||
Packet.EndedAtUtc = TEXT("2026-04-25T12:00:01Z");
|
||||
Packet.Events = {PreviewEvent, CommitEvent};
|
||||
Packet.DerivedSummary.TotalTimeMs = 420;
|
||||
Packet.DerivedSummary.RecognizedSegments = 1;
|
||||
Packet.DerivedSummary.ConfidenceRollup = 0.96f;
|
||||
Packet.DerivedSummary.Result = TEXT("committed");
|
||||
return Packet;
|
||||
}
|
||||
|
||||
FHyperTwistVisionSessionConfig UHyperTwistContractLibrary::MakeSampleVisionSessionConfig()
|
||||
{
|
||||
FHyperTwistVisionSessionConfig Config;
|
||||
Config.SessionId = TEXT("vision_01");
|
||||
Config.PuzzleId = TEXT("cube/3x3x3");
|
||||
Config.ExpectedPuzzleFamily = EHyperTwistPuzzleFamily::ClassicCube;
|
||||
Config.NotationProfile = TEXT("classic-wca");
|
||||
Config.FrameSize = FIntPoint(1280, 720);
|
||||
Config.MaxFrameRate = 30;
|
||||
return Config;
|
||||
}
|
||||
|
||||
FHyperTwistVisionPreviewResult UHyperTwistContractLibrary::MakeMockVisionPreviewResult()
|
||||
{
|
||||
FHyperTwistVisionPreviewResult Result;
|
||||
Result.SessionId = TEXT("vision_01");
|
||||
Result.FrameId = TEXT("frame_10");
|
||||
Result.PreviewConfidence = 0.84f;
|
||||
Result.PreviewState.SnapshotId = TEXT("snap_prev_10");
|
||||
Result.PreviewState.State = MakeSampleClassicRecognitionPreviewState();
|
||||
Result.PreviewState.DerivedHash = TEXT("preview_hash");
|
||||
Result.Guidance = TEXT("capture-ready");
|
||||
return Result;
|
||||
}
|
||||
|
||||
FHyperTwistVisionCommitResult UHyperTwistContractLibrary::MakeMockVisionCommitResult()
|
||||
{
|
||||
FHyperTwistVisionCommitResult Result;
|
||||
Result.SessionId = TEXT("vision_01");
|
||||
Result.CommitKind = TEXT("face");
|
||||
Result.Snapshot.SnapshotId = TEXT("snap_commit");
|
||||
Result.Snapshot.State = MakeSampleClassicPuzzleState();
|
||||
Result.Snapshot.State.Source = EHyperTwistStateSource::Recognition;
|
||||
Result.Snapshot.State.SourceConfidence = 0.96f;
|
||||
Result.Snapshot.State.SourceSessionId = TEXT("vision_01");
|
||||
Result.Snapshot.DerivedHash = TEXT("commit_hash");
|
||||
Result.Confidence = 0.96f;
|
||||
Result.CommittedUnit = TEXT("F");
|
||||
return Result;
|
||||
}
|
||||
|
||||
FHyperTwistVisionFinalizeResult UHyperTwistContractLibrary::MakeMockVisionFinalizeResult()
|
||||
{
|
||||
FHyperTwistVisionFinalizeResult Result;
|
||||
Result.SessionId = TEXT("vision_01");
|
||||
Result.FinalState = MakeSampleClassicPuzzleState();
|
||||
Result.FinalState.Source = EHyperTwistStateSource::Recognition;
|
||||
Result.FinalState.SourceConfidence = 0.97f;
|
||||
Result.FinalState.SourceSessionId = TEXT("vision_01");
|
||||
Result.FinalSnapshot.SnapshotId = TEXT("snap_final");
|
||||
Result.FinalSnapshot.State = Result.FinalState;
|
||||
Result.FinalSnapshot.DerivedHash = TEXT("final_hash");
|
||||
Result.ReplaySeedEventsJson.Add(SerializeReplayPacketToJson(MakeSampleRecognitionReplayPacket()));
|
||||
Result.ConfidenceRollup = 0.97f;
|
||||
return Result;
|
||||
}
|
||||
|
||||
FHyperTwistVisionServiceHealth UHyperTwistContractLibrary::MakeMockVisionServiceHealth()
|
||||
{
|
||||
FHyperTwistVisionServiceHealth Health;
|
||||
Health.ServiceVersion = TEXT("mock-vision/v1");
|
||||
Health.Capabilities = {TEXT("liveCamera3x3"), TEXT("faceCommitFlow"), TEXT("calibrationProfiles")};
|
||||
Health.bReady = true;
|
||||
return Health;
|
||||
}
|
||||
|
||||
bool UHyperTwistContractLibrary::IsPuzzleStateStructurallyValid(const FHyperTwistPuzzleState& State)
|
||||
{
|
||||
return State.IsStructurallyValid();
|
||||
}
|
||||
|
||||
bool UHyperTwistContractLibrary::IsReplayPacketStructurallyValid(const FHyperTwistReplayPacket& Packet)
|
||||
{
|
||||
return Packet.IsStructurallyValid();
|
||||
}
|
||||
|
||||
FString UHyperTwistContractLibrary::SerializePuzzleStateToJson(const FHyperTwistPuzzleState& State)
|
||||
{
|
||||
return HyperTwistContractLibraryInternal::SerializeStructToJson(State);
|
||||
}
|
||||
|
||||
FString UHyperTwistContractLibrary::SerializeReplayPacketToJson(const FHyperTwistReplayPacket& Packet)
|
||||
{
|
||||
return HyperTwistContractLibraryInternal::SerializeStructToJson(Packet);
|
||||
}
|
||||
|
||||
bool UHyperTwistContractLibrary::DeserializePuzzleStateFromJson(const FString& Json, FHyperTwistPuzzleState& OutState)
|
||||
{
|
||||
return HyperTwistContractLibraryInternal::DeserializeStructFromJson(Json, OutState);
|
||||
}
|
||||
|
||||
bool UHyperTwistContractLibrary::DeserializeReplayPacketFromJson(const FString& Json, FHyperTwistReplayPacket& OutPacket)
|
||||
{
|
||||
return HyperTwistContractLibraryInternal::DeserializeStructFromJson(Json, OutPacket);
|
||||
}
|
||||
|
|
@ -0,0 +1,218 @@
|
|||
#include "HyperTwistCore/HyperTwistCoreLibrary.h"
|
||||
|
||||
#include "JsonObjectConverter.h"
|
||||
|
||||
namespace HyperTwistCoreLibraryInternal
|
||||
{
|
||||
template <typename TStruct>
|
||||
bool DeserializePayload(const FHyperTwistSerializedPayload& Payload, TStruct& OutValue)
|
||||
{
|
||||
if (Payload.PayloadJson.IsEmpty())
|
||||
{
|
||||
return false;
|
||||
}
|
||||
|
||||
return FJsonObjectConverter::JsonObjectStringToUStruct(Payload.PayloadJson, &OutValue, 0, 0);
|
||||
}
|
||||
|
||||
bool IsIdentityPermutation(const TArray<int32>& Values)
|
||||
{
|
||||
for (int32 Index = 0; Index < Values.Num(); ++Index)
|
||||
{
|
||||
if (Values[Index] != Index)
|
||||
{
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
return true;
|
||||
}
|
||||
|
||||
bool IsZeroOrientation(const TArray<int32>& Values)
|
||||
{
|
||||
for (const int32 Value : Values)
|
||||
{
|
||||
if (Value != 0)
|
||||
{
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
return true;
|
||||
}
|
||||
|
||||
bool IsUniformFace(const TArray<FString>& Facelets)
|
||||
{
|
||||
if (Facelets.Num() == 0)
|
||||
{
|
||||
return false;
|
||||
}
|
||||
|
||||
const FString& Reference = Facelets[0];
|
||||
for (const FString& Facelet : Facelets)
|
||||
{
|
||||
if (Facelet != Reference)
|
||||
{
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
return true;
|
||||
}
|
||||
|
||||
bool IsCanonicalLabelSequence(const TArray<FString>& Labels, const FString& Prefix)
|
||||
{
|
||||
for (int32 Index = 0; Index < Labels.Num(); ++Index)
|
||||
{
|
||||
if (Labels[Index] != FString::Printf(TEXT("%s%d"), *Prefix, Index))
|
||||
{
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
return Labels.Num() > 0;
|
||||
}
|
||||
}
|
||||
|
||||
FHyperTwistNotationNormalizationResult UHyperTwistCoreLibrary::NormalizeNotation(const FString& RawNotation)
|
||||
{
|
||||
FHyperTwistNotationNormalizationResult Result;
|
||||
Result.InputNotation = RawNotation;
|
||||
|
||||
FString Working = RawNotation;
|
||||
Working.TrimStartAndEndInline();
|
||||
Working.ReplaceInline(TEXT("\r"), TEXT(" "));
|
||||
Working.ReplaceInline(TEXT("\n"), TEXT(" "));
|
||||
Working.ReplaceInline(TEXT("\t"), TEXT(" "));
|
||||
Working.ReplaceInline(TEXT("’"), TEXT("'"));
|
||||
Working.ReplaceInline(TEXT("`"), TEXT("'"));
|
||||
|
||||
while (Working.Contains(TEXT(" ")))
|
||||
{
|
||||
Working.ReplaceInline(TEXT(" "), TEXT(" "));
|
||||
}
|
||||
|
||||
Result.NormalizedNotation = Working;
|
||||
Result.bIsValid = !Working.IsEmpty();
|
||||
Result.bWasModified = Working != RawNotation;
|
||||
|
||||
if (Result.bWasModified)
|
||||
{
|
||||
Result.Warnings.Add(TEXT("notation-normalized"));
|
||||
}
|
||||
|
||||
if (!Result.bIsValid)
|
||||
{
|
||||
Result.Warnings.Add(TEXT("notation-empty-after-normalization"));
|
||||
}
|
||||
|
||||
return Result;
|
||||
}
|
||||
|
||||
bool UHyperTwistCoreLibrary::IsSolved(const FHyperTwistPuzzleState& State)
|
||||
{
|
||||
if (!State.IsStructurallyValid())
|
||||
{
|
||||
return false;
|
||||
}
|
||||
|
||||
if (State.bIsSolved)
|
||||
{
|
||||
return true;
|
||||
}
|
||||
|
||||
if (State.StateEncoding.EncodingProfile == TEXT("classic-piece-orbit-v1"))
|
||||
{
|
||||
FHyperTwistClassicPieceOrbitState OrbitState;
|
||||
if (!HyperTwistCoreLibraryInternal::DeserializePayload(State.StateEncoding, OrbitState))
|
||||
{
|
||||
return false;
|
||||
}
|
||||
|
||||
return HyperTwistCoreLibraryInternal::IsIdentityPermutation(OrbitState.Corners.Permutation)
|
||||
&& HyperTwistCoreLibraryInternal::IsZeroOrientation(OrbitState.Corners.Orientation)
|
||||
&& HyperTwistCoreLibraryInternal::IsIdentityPermutation(OrbitState.Edges.Permutation)
|
||||
&& HyperTwistCoreLibraryInternal::IsZeroOrientation(OrbitState.Edges.Orientation)
|
||||
&& HyperTwistCoreLibraryInternal::IsIdentityPermutation(OrbitState.Centers.Permutation)
|
||||
&& HyperTwistCoreLibraryInternal::IsZeroOrientation(OrbitState.Centers.Orientation);
|
||||
}
|
||||
|
||||
if (State.StateEncoding.EncodingProfile == TEXT("classic-facelet-snapshot-v1"))
|
||||
{
|
||||
FHyperTwistClassicFaceletSnapshotState FaceletState;
|
||||
if (!HyperTwistCoreLibraryInternal::DeserializePayload(State.StateEncoding, FaceletState))
|
||||
{
|
||||
return false;
|
||||
}
|
||||
|
||||
return HyperTwistCoreLibraryInternal::IsUniformFace(FaceletState.U)
|
||||
&& HyperTwistCoreLibraryInternal::IsUniformFace(FaceletState.R)
|
||||
&& HyperTwistCoreLibraryInternal::IsUniformFace(FaceletState.F)
|
||||
&& HyperTwistCoreLibraryInternal::IsUniformFace(FaceletState.D)
|
||||
&& HyperTwistCoreLibraryInternal::IsUniformFace(FaceletState.L)
|
||||
&& HyperTwistCoreLibraryInternal::IsUniformFace(FaceletState.B);
|
||||
}
|
||||
|
||||
if (State.StateEncoding.EncodingProfile == TEXT("hypercube-piece-map-v1"))
|
||||
{
|
||||
FHyperTwistHypercubePieceMapState HyperState;
|
||||
if (!HyperTwistCoreLibraryInternal::DeserializePayload(State.StateEncoding, HyperState))
|
||||
{
|
||||
return false;
|
||||
}
|
||||
|
||||
return HyperTwistCoreLibraryInternal::IsCanonicalLabelSequence(HyperState.Corners, TEXT("c"))
|
||||
&& HyperTwistCoreLibraryInternal::IsCanonicalLabelSequence(HyperState.Edges, TEXT("e"))
|
||||
&& HyperTwistCoreLibraryInternal::IsCanonicalLabelSequence(HyperState.Faces, TEXT("f"))
|
||||
&& HyperTwistCoreLibraryInternal::IsCanonicalLabelSequence(HyperState.Cells, TEXT("cell"));
|
||||
}
|
||||
|
||||
return false;
|
||||
}
|
||||
|
||||
FHyperTwistApplyTransformationResult UHyperTwistCoreLibrary::ApplyTransformation(const FHyperTwistPuzzleState& State, const FHyperTwistTransformation& Transformation)
|
||||
{
|
||||
FHyperTwistApplyTransformationResult Result;
|
||||
Result.State = State;
|
||||
|
||||
if (!State.IsStructurallyValid())
|
||||
{
|
||||
Result.Warnings.Add(TEXT("invalid-input-state"));
|
||||
return Result;
|
||||
}
|
||||
|
||||
if (!Transformation.IsStructurallyValid())
|
||||
{
|
||||
Result.Warnings.Add(TEXT("invalid-transformation"));
|
||||
return Result;
|
||||
}
|
||||
|
||||
const FHyperTwistNotationNormalizationResult Normalization = NormalizeNotation(Transformation.Notation);
|
||||
Result.AppliedNotation = Normalization.NormalizedNotation;
|
||||
Result.Warnings.Append(Normalization.Warnings);
|
||||
|
||||
if (!Normalization.bIsValid)
|
||||
{
|
||||
return Result;
|
||||
}
|
||||
|
||||
Result.bApplied = true;
|
||||
|
||||
if (Normalization.NormalizedNotation.Equals(TEXT("I"), ESearchCase::IgnoreCase)
|
||||
|| Normalization.NormalizedNotation.Equals(TEXT("identity"), ESearchCase::IgnoreCase))
|
||||
{
|
||||
Result.bExactStateUpdate = true;
|
||||
Result.State.bIsSolved = IsSolved(State);
|
||||
return Result;
|
||||
}
|
||||
|
||||
Result.bExactStateUpdate = false;
|
||||
Result.State.bIsSolved = false;
|
||||
Result.State.Source = EHyperTwistStateSource::Runtime;
|
||||
Result.State.Notes = FString::Printf(
|
||||
TEXT("placeholder-transform-application:%s"),
|
||||
*Normalization.NormalizedNotation
|
||||
);
|
||||
Result.Warnings.Add(TEXT("exact-piece-update-pending"));
|
||||
return Result;
|
||||
}
|
||||
|
|
@ -0,0 +1,76 @@
|
|||
#include "HyperTwistRecognition/HyperTwistVisionClient.h"
|
||||
|
||||
#include "HyperTwistBootstrap/HyperTwistContractLibrary.h"
|
||||
|
||||
bool UHyperTwistMockVisionClient::OpenVisionSession(const FHyperTwistVisionSessionConfig& Config, FString& OutError)
|
||||
{
|
||||
OutError.Reset();
|
||||
|
||||
if (Config.SessionId.IsEmpty())
|
||||
{
|
||||
OutError = TEXT("session-id-required");
|
||||
return false;
|
||||
}
|
||||
|
||||
SessionConfigs.Add(Config.SessionId, Config);
|
||||
SessionFrameCounts.Add(Config.SessionId, 0);
|
||||
return true;
|
||||
}
|
||||
|
||||
FHyperTwistVisionPreviewResult UHyperTwistMockVisionClient::SubmitVisionFrame(const FHyperTwistVisionFrameEnvelope& Frame)
|
||||
{
|
||||
FHyperTwistVisionPreviewResult Result = UHyperTwistContractLibrary::MakeMockVisionPreviewResult();
|
||||
Result.SessionId = Frame.SessionId;
|
||||
Result.FrameId = Frame.FrameId;
|
||||
Result.PreviewState.State.SourceSessionId = Frame.SessionId;
|
||||
|
||||
const int32 NextFrameCount = SessionFrameCounts.FindRef(Frame.SessionId) + 1;
|
||||
SessionFrameCounts.Add(Frame.SessionId, NextFrameCount);
|
||||
Result.Guidance = NextFrameCount >= 3 ? TEXT("commit-ready") : TEXT("keep-scanning");
|
||||
|
||||
return Result;
|
||||
}
|
||||
|
||||
FHyperTwistVisionCommitResult UHyperTwistMockVisionClient::CommitVisionObservation(const FHyperTwistVisionCommitRequest& Request)
|
||||
{
|
||||
FHyperTwistVisionCommitResult Result = UHyperTwistContractLibrary::MakeMockVisionCommitResult();
|
||||
Result.SessionId = Request.SessionId;
|
||||
Result.CommitKind = Request.CommitKind;
|
||||
Result.CommittedUnit = !Request.TargetFace.IsEmpty() ? Request.TargetFace : Request.TargetStage;
|
||||
Result.Snapshot.State.SourceSessionId = Request.SessionId;
|
||||
|
||||
if (!SessionConfigs.Contains(Request.SessionId))
|
||||
{
|
||||
Result.Warnings.Add(TEXT("session-not-open"));
|
||||
Result.Confidence = 0.0f;
|
||||
}
|
||||
|
||||
return Result;
|
||||
}
|
||||
|
||||
FHyperTwistVisionFinalizeResult UHyperTwistMockVisionClient::FinalizeVisionSession(const FString& SessionId)
|
||||
{
|
||||
FHyperTwistVisionFinalizeResult Result = UHyperTwistContractLibrary::MakeMockVisionFinalizeResult();
|
||||
Result.SessionId = SessionId;
|
||||
Result.FinalState.SourceSessionId = SessionId;
|
||||
Result.FinalSnapshot.State.SourceSessionId = SessionId;
|
||||
|
||||
if (!SessionConfigs.Contains(SessionId))
|
||||
{
|
||||
Result.NormalizationWarnings.Add(TEXT("session-not-open"));
|
||||
}
|
||||
else
|
||||
{
|
||||
SessionConfigs.Remove(SessionId);
|
||||
SessionFrameCounts.Remove(SessionId);
|
||||
}
|
||||
|
||||
return Result;
|
||||
}
|
||||
|
||||
FHyperTwistVisionServiceHealth UHyperTwistMockVisionClient::GetVisionServiceHealth() const
|
||||
{
|
||||
FHyperTwistVisionServiceHealth Health = UHyperTwistContractLibrary::MakeMockVisionServiceHealth();
|
||||
Health.Capabilities.Add(TEXT("sessioned-mock-client"));
|
||||
return Health;
|
||||
}
|
||||
|
|
@ -0,0 +1,152 @@
|
|||
#include "HyperTwistReplay/HyperTwistReplayLibrary.h"
|
||||
|
||||
#include "JsonObjectConverter.h"
|
||||
|
||||
namespace HyperTwistReplayLibraryInternal
|
||||
{
|
||||
template <typename TStruct>
|
||||
bool DeserializePayload(const FString& Json, TStruct& OutValue)
|
||||
{
|
||||
if (Json.IsEmpty())
|
||||
{
|
||||
return false;
|
||||
}
|
||||
|
||||
return FJsonObjectConverter::JsonObjectStringToUStruct(Json, &OutValue, 0, 0);
|
||||
}
|
||||
}
|
||||
|
||||
FHyperTwistReplayPacket UHyperTwistReplayLibrary::AppendReplayEvent(const FHyperTwistReplayPacket& Packet, const FHyperTwistReplayEvent& Event)
|
||||
{
|
||||
FHyperTwistReplayPacket UpdatedPacket = Packet;
|
||||
FHyperTwistReplayEvent UpdatedEvent = Event;
|
||||
|
||||
const int32 LastSequence = UpdatedPacket.Events.Num() > 0 ? UpdatedPacket.Events.Last().Sequence : 0;
|
||||
const int32 LastTimeMs = UpdatedPacket.Events.Num() > 0 ? UpdatedPacket.Events.Last().TimeMs : 0;
|
||||
|
||||
if (UpdatedEvent.Sequence <= LastSequence)
|
||||
{
|
||||
UpdatedEvent.Sequence = LastSequence + 1;
|
||||
}
|
||||
|
||||
if (UpdatedEvent.TimeMs < LastTimeMs)
|
||||
{
|
||||
UpdatedEvent.TimeMs = LastTimeMs;
|
||||
}
|
||||
|
||||
if (UpdatedEvent.EventId.IsEmpty())
|
||||
{
|
||||
UpdatedEvent.EventId = FString::Printf(TEXT("evt_%03d"), UpdatedEvent.Sequence);
|
||||
}
|
||||
|
||||
UpdatedPacket.Events.Add(UpdatedEvent);
|
||||
UpdatedPacket.DerivedSummary = DeriveReplaySummary(UpdatedPacket);
|
||||
return UpdatedPacket;
|
||||
}
|
||||
|
||||
FHyperTwistDerivedReplaySummary UHyperTwistReplayLibrary::DeriveReplaySummary(const FHyperTwistReplayPacket& Packet)
|
||||
{
|
||||
FHyperTwistDerivedReplaySummary Summary;
|
||||
if (Packet.Events.Num() == 0)
|
||||
{
|
||||
return Summary;
|
||||
}
|
||||
|
||||
int32 TimerStartMs = INDEX_NONE;
|
||||
float ConfidenceSum = 0.0f;
|
||||
int32 ConfidenceCount = 0;
|
||||
|
||||
TMap<FString, FHyperTwistPhaseTiming> OpenPhaseTimings;
|
||||
|
||||
for (const FHyperTwistReplayEvent& Event : Packet.Events)
|
||||
{
|
||||
Summary.TotalTimeMs = FMath::Max(Summary.TotalTimeMs, Event.TimeMs);
|
||||
|
||||
switch (Event.EventType)
|
||||
{
|
||||
case EHyperTwistReplayEventType::TimerStart:
|
||||
if (TimerStartMs == INDEX_NONE)
|
||||
{
|
||||
TimerStartMs = Event.TimeMs;
|
||||
Summary.InspectionTimeMs = TimerStartMs;
|
||||
}
|
||||
break;
|
||||
|
||||
case EHyperTwistReplayEventType::Move:
|
||||
++Summary.MoveCount;
|
||||
break;
|
||||
|
||||
case EHyperTwistReplayEventType::RecognitionCommit:
|
||||
++Summary.RecognizedSegments;
|
||||
// intentional fallthrough
|
||||
case EHyperTwistReplayEventType::RecognitionPreview:
|
||||
case EHyperTwistReplayEventType::RecognitionScan:
|
||||
case EHyperTwistReplayEventType::RecognitionCorrection:
|
||||
{
|
||||
FHyperTwistReplayRecognitionPayload RecognitionPayload;
|
||||
if (HyperTwistReplayLibraryInternal::DeserializePayload(Event.PayloadJson, RecognitionPayload))
|
||||
{
|
||||
ConfidenceSum += RecognitionPayload.Confidence;
|
||||
++ConfidenceCount;
|
||||
}
|
||||
break;
|
||||
}
|
||||
|
||||
case EHyperTwistReplayEventType::PhaseMark:
|
||||
{
|
||||
FHyperTwistReplayPhaseMarkPayload PhasePayload;
|
||||
if (HyperTwistReplayLibraryInternal::DeserializePayload(Event.PayloadJson, PhasePayload)
|
||||
&& !PhasePayload.PhaseId.IsEmpty())
|
||||
{
|
||||
const FString Action = PhasePayload.PhaseAction.ToLower();
|
||||
if (Action == TEXT("start"))
|
||||
{
|
||||
FHyperTwistPhaseTiming& PhaseTiming = OpenPhaseTimings.FindOrAdd(PhasePayload.PhaseId);
|
||||
PhaseTiming.PhaseKind = PhasePayload.PhaseKind;
|
||||
PhaseTiming.StartedAtMs = Event.TimeMs;
|
||||
}
|
||||
else if ((Action == TEXT("end") || Action == TEXT("complete")) && OpenPhaseTimings.Contains(PhasePayload.PhaseId))
|
||||
{
|
||||
FHyperTwistPhaseTiming PhaseTiming = OpenPhaseTimings[PhasePayload.PhaseId];
|
||||
PhaseTiming.EndedAtMs = Event.TimeMs;
|
||||
PhaseTiming.DurationMs = FMath::Max(0, PhaseTiming.EndedAtMs - PhaseTiming.StartedAtMs);
|
||||
Summary.PhaseTimings.Add(PhaseTiming);
|
||||
OpenPhaseTimings.Remove(PhasePayload.PhaseId);
|
||||
}
|
||||
}
|
||||
break;
|
||||
}
|
||||
|
||||
case EHyperTwistReplayEventType::SolveEnd:
|
||||
Summary.Result = TEXT("completed");
|
||||
break;
|
||||
|
||||
default:
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
for (TPair<FString, FHyperTwistPhaseTiming>& Pair : OpenPhaseTimings)
|
||||
{
|
||||
Pair.Value.EndedAtMs = Summary.TotalTimeMs;
|
||||
Pair.Value.DurationMs = FMath::Max(0, Pair.Value.EndedAtMs - Pair.Value.StartedAtMs);
|
||||
Summary.PhaseTimings.Add(Pair.Value);
|
||||
}
|
||||
|
||||
if (Summary.Result.IsEmpty())
|
||||
{
|
||||
Summary.Result = TEXT("in-progress");
|
||||
}
|
||||
|
||||
if (ConfidenceCount > 0)
|
||||
{
|
||||
Summary.ConfidenceRollup = ConfidenceSum / static_cast<float>(ConfidenceCount);
|
||||
}
|
||||
|
||||
if (Summary.TotalTimeMs > 0)
|
||||
{
|
||||
Summary.TPS = static_cast<float>(Summary.MoveCount) / (static_cast<float>(Summary.TotalTimeMs) / 1000.0f);
|
||||
}
|
||||
|
||||
return Summary;
|
||||
}
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
#include "HyperTwistSimulation/HyperTwistSimulationLibrary.h"
|
||||
|
||||
#include "HyperTwistBootstrap/HyperTwistContractLibrary.h"
|
||||
|
||||
FHyperTwistSimulationSceneContext UHyperTwistSimulationLibrary::MakeClassicPlaceholderSceneContext()
|
||||
{
|
||||
FHyperTwistSimulationSceneContext SceneContext;
|
||||
SceneContext.SceneContextId = TEXT("scene_classic_placeholder");
|
||||
SceneContext.PuzzleState = UHyperTwistContractLibrary::MakeSampleClassicPuzzleState();
|
||||
SceneContext.ProjectionSettings.ProjectionKind = EHyperTwistProjectionKind::ClassicPerspective;
|
||||
SceneContext.ProjectionSettings.ProjectionProfile = TEXT("classic-default");
|
||||
SceneContext.RenderStateProfile = TEXT("classic-placeholder-render-state");
|
||||
return SceneContext;
|
||||
}
|
||||
|
||||
FHyperTwistSimulationSceneContext UHyperTwistSimulationLibrary::MakeHyperPlaceholderSceneContext()
|
||||
{
|
||||
FHyperTwistSimulationSceneContext SceneContext;
|
||||
SceneContext.SceneContextId = TEXT("scene_hyper_placeholder");
|
||||
SceneContext.PuzzleState = UHyperTwistContractLibrary::MakeSampleHyperPuzzleState();
|
||||
SceneContext.ProjectionSettings.ProjectionKind = EHyperTwistProjectionKind::HyperProjection;
|
||||
SceneContext.ProjectionSettings.ProjectionProfile = TEXT("hyper-default");
|
||||
SceneContext.ProjectionSettings.ProjectionDepth = 2.0f;
|
||||
SceneContext.RenderStateProfile = TEXT("hyper-placeholder-render-state");
|
||||
return SceneContext;
|
||||
}
|
||||
|
||||
bool UHyperTwistSimulationLibrary::CanRenderSceneContext(const FHyperTwistSimulationSceneContext& SceneContext)
|
||||
{
|
||||
return SceneContext.IsStructurallyValid();
|
||||
}
|
||||
|
|
@ -0,0 +1,241 @@
|
|||
#include "HyperTwistTraining/HyperTwistTrainingLibrary.h"
|
||||
|
||||
namespace HyperTwistTrainingLibraryInternal
|
||||
{
|
||||
bool MatchesPuzzleFamily(const FString& PuzzleId, EHyperTwistPuzzleFamily PuzzleFamily)
|
||||
{
|
||||
switch (PuzzleFamily)
|
||||
{
|
||||
case EHyperTwistPuzzleFamily::ClassicCube:
|
||||
return PuzzleId.StartsWith(TEXT("cube/"));
|
||||
case EHyperTwistPuzzleFamily::Hypercube:
|
||||
return PuzzleId.StartsWith(TEXT("hypercube/"));
|
||||
default:
|
||||
return !PuzzleId.IsEmpty();
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
FHyperTwistContentPack UHyperTwistTrainingLibrary::MakeSampleClassicContentPack()
|
||||
{
|
||||
FHyperTwistTrainingCase CaseA;
|
||||
CaseA.CaseId = TEXT("cross-case-01");
|
||||
CaseA.PuzzleId = TEXT("cube/3x3x3");
|
||||
CaseA.PromptKind = EHyperTwistTrainingPromptKind::Algorithm;
|
||||
CaseA.CanonicalNotation = TEXT("R F");
|
||||
CaseA.Difficulty = 0.2f;
|
||||
CaseA.Tags = {TEXT("cross"), TEXT("seed")};
|
||||
CaseA.AllowedDeliveryModes = {EHyperTwistTrainingDeliveryMode::Timer, EHyperTwistTrainingDeliveryMode::VirtualCube};
|
||||
CaseA.TimeTargetMs = 3000;
|
||||
|
||||
FHyperTwistTrainingCase CaseB;
|
||||
CaseB.CaseId = TEXT("cross-case-02");
|
||||
CaseB.PuzzleId = TEXT("cube/3x3x3");
|
||||
CaseB.PromptKind = EHyperTwistTrainingPromptKind::Algorithm;
|
||||
CaseB.CanonicalNotation = TEXT("F U R");
|
||||
CaseB.Difficulty = 0.35f;
|
||||
CaseB.Tags = {TEXT("cross"), TEXT("seed")};
|
||||
CaseB.AllowedDeliveryModes = {EHyperTwistTrainingDeliveryMode::Timer, EHyperTwistTrainingDeliveryMode::VirtualCube};
|
||||
CaseB.TimeTargetMs = 3500;
|
||||
|
||||
FHyperTwistTrainingDeck Deck;
|
||||
Deck.DeckId = TEXT("cross-1-to-8");
|
||||
Deck.Title = TEXT("Cross 1 to 8");
|
||||
Deck.DeliveryModes = {EHyperTwistTrainingDeliveryMode::Timer, EHyperTwistTrainingDeliveryMode::VirtualCube};
|
||||
Deck.SelectionPolicy = EHyperTwistTrainingSelectionPolicy::Weighted;
|
||||
Deck.Cases = {CaseA, CaseB};
|
||||
Deck.DifficultyBand = TEXT("starter");
|
||||
Deck.Tags = {TEXT("classic"), TEXT("cross")};
|
||||
|
||||
FHyperTwistTrainingTrack Track;
|
||||
Track.TrackId = TEXT("cross");
|
||||
Track.Title = TEXT("Cross");
|
||||
Track.Goal = TEXT("build fast and consistent cross execution");
|
||||
Track.Decks = {Deck};
|
||||
|
||||
FHyperTwistContentPack ContentPack;
|
||||
ContentPack.ContentPackId = TEXT("classic-3x3-core");
|
||||
ContentPack.Title = TEXT("Classic 3x3 Core");
|
||||
ContentPack.Version = TEXT("2026.04");
|
||||
ContentPack.PuzzleFamily = EHyperTwistPuzzleFamily::ClassicCube;
|
||||
ContentPack.NotationProfile = TEXT("classic-wca");
|
||||
ContentPack.Tracks = {Track};
|
||||
return ContentPack;
|
||||
}
|
||||
|
||||
bool UHyperTwistTrainingLibrary::IsTrainingCaseCompatibleWithPack(
|
||||
const FHyperTwistTrainingCase& TrainingCase,
|
||||
const FHyperTwistContentPack& ContentPack
|
||||
)
|
||||
{
|
||||
return TrainingCase.IsStructurallyValid()
|
||||
&& ContentPack.IsStructurallyValid()
|
||||
&& !ContentPack.NotationProfile.IsEmpty()
|
||||
&& HyperTwistTrainingLibraryInternal::MatchesPuzzleFamily(TrainingCase.PuzzleId, ContentPack.PuzzleFamily);
|
||||
}
|
||||
|
||||
bool UHyperTwistTrainingLibrary::CanStartTrainingSession(
|
||||
const FHyperTwistTrainingDeck& Deck,
|
||||
const FHyperTwistContentPack& ContentPack
|
||||
)
|
||||
{
|
||||
if (!Deck.IsStructurallyValid() || !ContentPack.IsStructurallyValid())
|
||||
{
|
||||
return false;
|
||||
}
|
||||
|
||||
for (const FHyperTwistTrainingCase& TrainingCase : Deck.Cases)
|
||||
{
|
||||
if (!IsTrainingCaseCompatibleWithPack(TrainingCase, ContentPack))
|
||||
{
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
return true;
|
||||
}
|
||||
|
||||
FHyperTwistTrainingSession UHyperTwistTrainingLibrary::StartTrainingSession(
|
||||
const FHyperTwistTrainingDeck& Deck,
|
||||
const FString& UserId,
|
||||
const FString& SessionId,
|
||||
EHyperTwistTrainingDeliveryMode Mode
|
||||
)
|
||||
{
|
||||
FHyperTwistTrainingSession UpdatedSession;
|
||||
UpdatedSession.TrainingSessionId = SessionId.IsEmpty() ? TEXT("training_session_01") : SessionId;
|
||||
UpdatedSession.DeckId = Deck.DeckId;
|
||||
UpdatedSession.UserId = UserId.IsEmpty() ? TEXT("local-user") : UserId;
|
||||
UpdatedSession.StartedAtUtc = TEXT("2026-04-25T12:00:00Z");
|
||||
UpdatedSession.Mode = Mode;
|
||||
UpdatedSession.SelectionPolicy = Deck.SelectionPolicy;
|
||||
UpdatedSession.SessionState = Deck.IsStructurallyValid()
|
||||
? EHyperTwistTrainingSessionState::Ready
|
||||
: EHyperTwistTrainingSessionState::Created;
|
||||
if (Deck.Cases.Num() > 0)
|
||||
{
|
||||
UpdatedSession.CurrentCaseId = Deck.Cases[0].CaseId;
|
||||
}
|
||||
return UpdatedSession;
|
||||
}
|
||||
|
||||
bool UHyperTwistTrainingLibrary::CanTransitionTrainingSession(
|
||||
EHyperTwistTrainingSessionState FromState,
|
||||
EHyperTwistTrainingSessionState ToState
|
||||
)
|
||||
{
|
||||
switch (FromState)
|
||||
{
|
||||
case EHyperTwistTrainingSessionState::Created:
|
||||
return ToState == EHyperTwistTrainingSessionState::Ready;
|
||||
case EHyperTwistTrainingSessionState::Ready:
|
||||
return ToState == EHyperTwistTrainingSessionState::Active;
|
||||
case EHyperTwistTrainingSessionState::Active:
|
||||
return ToState == EHyperTwistTrainingSessionState::Paused
|
||||
|| ToState == EHyperTwistTrainingSessionState::Reviewing
|
||||
|| ToState == EHyperTwistTrainingSessionState::Completed
|
||||
|| ToState == EHyperTwistTrainingSessionState::Aborted;
|
||||
case EHyperTwistTrainingSessionState::Paused:
|
||||
return ToState == EHyperTwistTrainingSessionState::Active
|
||||
|| ToState == EHyperTwistTrainingSessionState::Aborted;
|
||||
case EHyperTwistTrainingSessionState::Reviewing:
|
||||
return ToState == EHyperTwistTrainingSessionState::Active
|
||||
|| ToState == EHyperTwistTrainingSessionState::Completed;
|
||||
default:
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
FHyperTwistTrainingSession UHyperTwistTrainingLibrary::AdvanceTrainingSession(
|
||||
const FHyperTwistTrainingSession& Session,
|
||||
EHyperTwistTrainingSessionState TargetState,
|
||||
const FString& NextCaseId
|
||||
)
|
||||
{
|
||||
FHyperTwistTrainingSession UpdatedSession = Session;
|
||||
if (!CanTransitionTrainingSession(Session.SessionState, TargetState))
|
||||
{
|
||||
return UpdatedSession;
|
||||
}
|
||||
|
||||
UpdatedSession.SessionState = TargetState;
|
||||
|
||||
if (TargetState == EHyperTwistTrainingSessionState::Active || TargetState == EHyperTwistTrainingSessionState::Reviewing)
|
||||
{
|
||||
if (!NextCaseId.IsEmpty())
|
||||
{
|
||||
UpdatedSession.CurrentCaseId = NextCaseId;
|
||||
}
|
||||
}
|
||||
else if (TargetState == EHyperTwistTrainingSessionState::Completed || TargetState == EHyperTwistTrainingSessionState::Aborted)
|
||||
{
|
||||
UpdatedSession.EndedAtUtc = TEXT("2026-04-25T12:05:00Z");
|
||||
UpdatedSession.CurrentCaseId.Reset();
|
||||
}
|
||||
|
||||
return UpdatedSession;
|
||||
}
|
||||
|
||||
FHyperTwistTrainingSession UHyperTwistTrainingLibrary::RecordTrainingAttempt(
|
||||
const FHyperTwistTrainingSession& Session,
|
||||
const FHyperTwistTrainingAttempt& Attempt
|
||||
)
|
||||
{
|
||||
FHyperTwistTrainingSession UpdatedSession = Session;
|
||||
if (!Attempt.IsStructurallyValid())
|
||||
{
|
||||
return UpdatedSession;
|
||||
}
|
||||
|
||||
if (Session.SessionState != EHyperTwistTrainingSessionState::Active
|
||||
&& Session.SessionState != EHyperTwistTrainingSessionState::Reviewing)
|
||||
{
|
||||
return UpdatedSession;
|
||||
}
|
||||
|
||||
UpdatedSession.AttemptCount = Session.AttemptCount + 1;
|
||||
UpdatedSession.CurrentCaseId = Attempt.CaseId;
|
||||
UpdatedSession.SessionState = EHyperTwistTrainingSessionState::Reviewing;
|
||||
return UpdatedSession;
|
||||
}
|
||||
|
||||
FHyperTwistTrainingSession UHyperTwistTrainingLibrary::CompleteTrainingSession(
|
||||
const FHyperTwistTrainingSession& Session,
|
||||
bool bAbortSession
|
||||
)
|
||||
{
|
||||
FHyperTwistTrainingSession UpdatedSession = Session;
|
||||
const EHyperTwistTrainingSessionState TargetState = bAbortSession
|
||||
? EHyperTwistTrainingSessionState::Aborted
|
||||
: EHyperTwistTrainingSessionState::Completed;
|
||||
|
||||
if (!CanTransitionTrainingSession(Session.SessionState, TargetState)
|
||||
&& Session.SessionState != EHyperTwistTrainingSessionState::Reviewing)
|
||||
{
|
||||
return UpdatedSession;
|
||||
}
|
||||
|
||||
UpdatedSession.SessionState = TargetState;
|
||||
UpdatedSession.EndedAtUtc = TEXT("2026-04-25T12:05:00Z");
|
||||
UpdatedSession.CurrentCaseId.Reset();
|
||||
return UpdatedSession;
|
||||
}
|
||||
|
||||
FHyperTwistProgressionMemory UHyperTwistTrainingLibrary::MakeInitialProgressionMemory(
|
||||
const FHyperTwistTrainingSession& Session,
|
||||
const FHyperTwistTrainingCase& TrainingCase
|
||||
)
|
||||
{
|
||||
FHyperTwistProgressionMemory Memory;
|
||||
Memory.UserId = Session.UserId;
|
||||
Memory.DeckId = Session.DeckId;
|
||||
Memory.CaseId = TrainingCase.CaseId;
|
||||
Memory.StrengthScore = 0.0f;
|
||||
Memory.LastSeenAtUtc = Session.StartedAtUtc;
|
||||
Memory.LastOutcome = EHyperTwistTrainingAttemptResult::Failure;
|
||||
Memory.AttemptCount = 0;
|
||||
Memory.SuccessCount = 0;
|
||||
Memory.DifficultyWeight = TrainingCase.Difficulty <= 0.0f ? 1.0f : TrainingCase.Difficulty;
|
||||
Memory.ResurfacePriority = FMath::Max(1.0f, TrainingCase.Difficulty * 10.0f);
|
||||
return Memory;
|
||||
}
|
||||
|
|
@ -0,0 +1,72 @@
|
|||
#pragma once
|
||||
|
||||
#include "CoreMinimal.h"
|
||||
#include "Kismet/BlueprintFunctionLibrary.h"
|
||||
#include "HyperTwistCore/HyperTwistCoreTypes.h"
|
||||
#include "HyperTwistReplay/HyperTwistReplayTypes.h"
|
||||
#include "HyperTwistRecognition/HyperTwistRecognitionTypes.h"
|
||||
#include "HyperTwistContractLibrary.generated.h"
|
||||
|
||||
UCLASS()
|
||||
class UNREALHYPERTWIST_API UHyperTwistContractLibrary : public UBlueprintFunctionLibrary
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
public:
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Core")
|
||||
static FHyperTwistPuzzleDefinitionRef MakeSampleClassicPuzzleDefinition();
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Core")
|
||||
static FHyperTwistPuzzleDefinitionRef MakeSampleHyperPuzzleDefinition();
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Core")
|
||||
static FHyperTwistPuzzleState MakeSampleClassicPuzzleState();
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Core")
|
||||
static FHyperTwistPuzzleState MakeSampleClassicRecognitionPreviewState();
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Core")
|
||||
static FHyperTwistPuzzleState MakeSampleHyperPuzzleState();
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Core")
|
||||
static FHyperTwistTransformation MakeSampleClassicTransformation();
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Replay")
|
||||
static FHyperTwistReplayPacket MakeSampleRuntimeReplayPacket();
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Replay")
|
||||
static FHyperTwistReplayPacket MakeSampleRecognitionReplayPacket();
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Recognition")
|
||||
static FHyperTwistVisionSessionConfig MakeSampleVisionSessionConfig();
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Recognition")
|
||||
static FHyperTwistVisionPreviewResult MakeMockVisionPreviewResult();
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Recognition")
|
||||
static FHyperTwistVisionCommitResult MakeMockVisionCommitResult();
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Recognition")
|
||||
static FHyperTwistVisionFinalizeResult MakeMockVisionFinalizeResult();
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Recognition")
|
||||
static FHyperTwistVisionServiceHealth MakeMockVisionServiceHealth();
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Validation")
|
||||
static bool IsPuzzleStateStructurallyValid(const FHyperTwistPuzzleState& State);
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Validation")
|
||||
static bool IsReplayPacketStructurallyValid(const FHyperTwistReplayPacket& Packet);
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Serialization")
|
||||
static FString SerializePuzzleStateToJson(const FHyperTwistPuzzleState& State);
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Serialization")
|
||||
static FString SerializeReplayPacketToJson(const FHyperTwistReplayPacket& Packet);
|
||||
|
||||
UFUNCTION(BlueprintCallable, Category = "HyperTwist|Serialization")
|
||||
static bool DeserializePuzzleStateFromJson(const FString& Json, FHyperTwistPuzzleState& OutState);
|
||||
|
||||
UFUNCTION(BlueprintCallable, Category = "HyperTwist|Serialization")
|
||||
static bool DeserializeReplayPacketFromJson(const FString& Json, FHyperTwistReplayPacket& OutPacket);
|
||||
};
|
||||
|
|
@ -0,0 +1,64 @@
|
|||
#pragma once
|
||||
|
||||
#include "CoreMinimal.h"
|
||||
#include "Kismet/BlueprintFunctionLibrary.h"
|
||||
#include "HyperTwistCore/HyperTwistCoreTypes.h"
|
||||
#include "HyperTwistCoreLibrary.generated.h"
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistNotationNormalizationResult
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString InputNotation;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString NormalizedNotation;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> Warnings;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
bool bIsValid = false;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
bool bWasModified = false;
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistApplyTransformationResult
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistPuzzleState State;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString AppliedNotation;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> Warnings;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
bool bApplied = false;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
bool bExactStateUpdate = false;
|
||||
};
|
||||
|
||||
UCLASS()
|
||||
class UNREALHYPERTWIST_API UHyperTwistCoreLibrary : public UBlueprintFunctionLibrary
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
public:
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Core")
|
||||
static FHyperTwistNotationNormalizationResult NormalizeNotation(const FString& RawNotation);
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Core")
|
||||
static bool IsSolved(const FHyperTwistPuzzleState& State);
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Core")
|
||||
static FHyperTwistApplyTransformationResult ApplyTransformation(const FHyperTwistPuzzleState& State, const FHyperTwistTransformation& Transformation);
|
||||
};
|
||||
|
|
@ -0,0 +1,316 @@
|
|||
#pragma once
|
||||
|
||||
#include "CoreMinimal.h"
|
||||
#include "HyperTwistCoreTypes.generated.h"
|
||||
|
||||
UENUM(BlueprintType)
|
||||
enum class EHyperTwistPuzzleFamily : uint8
|
||||
{
|
||||
ClassicCube UMETA(DisplayName = "Classic Cube"),
|
||||
Hypercube UMETA(DisplayName = "Hypercube"),
|
||||
Tiling UMETA(DisplayName = "Tiling"),
|
||||
Other UMETA(DisplayName = "Other")
|
||||
};
|
||||
|
||||
UENUM(BlueprintType)
|
||||
enum class EHyperTwistStateEncodingKind : uint8
|
||||
{
|
||||
PieceOrbit UMETA(DisplayName = "Piece Orbit"),
|
||||
Facelet UMETA(DisplayName = "Facelet"),
|
||||
CellComplex UMETA(DisplayName = "Cell Complex"),
|
||||
FamilySpecific UMETA(DisplayName = "Family Specific")
|
||||
};
|
||||
|
||||
UENUM(BlueprintType)
|
||||
enum class EHyperTwistStateSource : uint8
|
||||
{
|
||||
Runtime UMETA(DisplayName = "Runtime"),
|
||||
Recognition UMETA(DisplayName = "Recognition"),
|
||||
SmartDevice UMETA(DisplayName = "Smart Device"),
|
||||
Import UMETA(DisplayName = "Import"),
|
||||
ManualEntry UMETA(DisplayName = "Manual Entry")
|
||||
};
|
||||
|
||||
UENUM(BlueprintType)
|
||||
enum class EHyperTwistTransformKind : uint8
|
||||
{
|
||||
SingleMove UMETA(DisplayName = "Single Move"),
|
||||
Algorithm UMETA(DisplayName = "Algorithm"),
|
||||
Rotation UMETA(DisplayName = "Rotation"),
|
||||
Slice UMETA(DisplayName = "Slice"),
|
||||
Composite UMETA(DisplayName = "Composite")
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistPuzzleDefinitionRef
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString PuzzleId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
EHyperTwistPuzzleFamily PuzzleFamily = EHyperTwistPuzzleFamily::ClassicCube;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 Dimension = 3;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString DefinitionVersion = TEXT("2026.04");
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString NotationProfile = TEXT("classic-wca");
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<int32> SizeVector;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString Variant;
|
||||
|
||||
bool IsStructurallyValid() const
|
||||
{
|
||||
return !PuzzleId.IsEmpty() && Dimension > 0 && !DefinitionVersion.IsEmpty() && !NotationProfile.IsEmpty();
|
||||
}
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistOrientationFrame
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString Reference = TEXT("canonical-default");
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistSerializedPayload
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString EncodingProfile;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString PayloadJson;
|
||||
|
||||
bool IsStructurallyValid() const
|
||||
{
|
||||
return !EncodingProfile.IsEmpty();
|
||||
}
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistPuzzleState
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString SchemaVersion = TEXT("ht-puzzle-state/v1");
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistPuzzleDefinitionRef Definition;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
EHyperTwistStateEncodingKind StateEncodingKind = EHyperTwistStateEncodingKind::PieceOrbit;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistSerializedPayload StateEncoding;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistOrientationFrame OrientationFrame;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
bool bIsSolved = false;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
EHyperTwistStateSource Source = EHyperTwistStateSource::Runtime;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString CapturedAtUtc;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
float SourceConfidence = -1.0f;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString SourceSessionId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString Notes;
|
||||
|
||||
bool IsStructurallyValid() const
|
||||
{
|
||||
return !SchemaVersion.IsEmpty() && Definition.IsStructurallyValid() && StateEncoding.IsStructurallyValid();
|
||||
}
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistTransformation
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistPuzzleDefinitionRef Definition;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
EHyperTwistTransformKind TransformKind = EHyperTwistTransformKind::SingleMove;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString Notation;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistSerializedPayload TransformEncoding;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
bool bInvertible = true;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString OriginalNotation;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> NormalizationWarnings;
|
||||
|
||||
bool IsStructurallyValid() const
|
||||
{
|
||||
return Definition.IsStructurallyValid() && !Notation.IsEmpty() && TransformEncoding.IsStructurallyValid();
|
||||
}
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistStateSnapshot
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString SnapshotId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistPuzzleState State;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString DerivedHash;
|
||||
|
||||
bool IsStructurallyValid() const
|
||||
{
|
||||
return !SnapshotId.IsEmpty() && State.IsStructurallyValid() && !DerivedHash.IsEmpty();
|
||||
}
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistPieceSetState
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<int32> Permutation;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<int32> Orientation;
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistClassicPieceOrbitState
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString EncodingProfile = TEXT("classic-piece-orbit-v1");
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistPieceSetState Corners;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistPieceSetState Edges;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistPieceSetState Centers;
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistClassicFaceletSnapshotState
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString EncodingProfile = TEXT("classic-facelet-snapshot-v1");
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> U;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> R;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> F;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> D;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> L;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> B;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
bool bPreviewState = true;
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistHypercubePieceMapState
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString EncodingProfile = TEXT("hypercube-piece-map-v1");
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> Corners;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> Edges;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> Faces;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> Cells;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString FrameProfile = TEXT("hypercube-canonical-v1");
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString TopologyVersion = TEXT("2x2x2x2/v1");
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistClassicTransformEncoding
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString EncodingProfile = TEXT("classic-transform-v1");
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> MoveSequence;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString CachedFamily = TEXT("classic-cube");
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistHypercubeTransformEncoding
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString EncodingProfile = TEXT("hypercube-transform-v1");
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString AxisRef;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString LayerSelector;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 TurnAmount = 1;
|
||||
};
|
||||
|
|
@ -0,0 +1,180 @@
|
|||
#pragma once
|
||||
|
||||
#include "CoreMinimal.h"
|
||||
#include "HyperTwistCore/HyperTwistCoreTypes.h"
|
||||
#include "HyperTwistRecognitionTypes.generated.h"
|
||||
|
||||
UENUM(BlueprintType)
|
||||
enum class EHyperTwistVisionCaptureMode : uint8
|
||||
{
|
||||
LiveCamera UMETA(DisplayName = "Live Camera"),
|
||||
BatchVideo UMETA(DisplayName = "Batch Video")
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistVisionSessionConfig
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString SessionId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString PuzzleId = TEXT("cube/3x3x3");
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
EHyperTwistVisionCaptureMode CaptureMode = EHyperTwistVisionCaptureMode::LiveCamera;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
EHyperTwistPuzzleFamily ExpectedPuzzleFamily = EHyperTwistPuzzleFamily::ClassicCube;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString NotationProfile = TEXT("classic-wca");
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString CameraProfile;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString CalibrationProfile;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FIntPoint FrameSize = FIntPoint(1280, 720);
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 MaxFrameRate = 30;
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistVisionFrameEnvelope
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString SessionId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString FrameId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString CapturedAtUtc;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 FrameOrdinal = 0;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString ImageRef;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString CameraPoseHint;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString ExposureHint;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 SourceTimestampMs = 0;
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistVisionPreviewResult
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString SessionId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString FrameId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
float PreviewConfidence = 0.0f;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistStateSnapshot PreviewState;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString Guidance;
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistVisionCommitRequest
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString SessionId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString CommitKind = TEXT("face");
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString TargetFace;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString TargetStage;
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistVisionCommitResult
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString SessionId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString CommitKind;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistStateSnapshot Snapshot;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
float Confidence = 0.0f;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString CommittedUnit;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> Warnings;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> MissingUnits;
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistVisionFinalizeResult
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString SessionId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistPuzzleState FinalState;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistStateSnapshot FinalSnapshot;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> ReplaySeedEventsJson;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
float ConfidenceRollup = 0.0f;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> NormalizationWarnings;
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistVisionServiceHealth
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString ServiceVersion = TEXT("mock-vision/v1");
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> Capabilities;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
bool bReady = true;
|
||||
};
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
#pragma once
|
||||
|
||||
#include "CoreMinimal.h"
|
||||
#include "UObject/Interface.h"
|
||||
#include "UObject/Object.h"
|
||||
#include "HyperTwistRecognition/HyperTwistRecognitionTypes.h"
|
||||
#include "HyperTwistVisionClient.generated.h"
|
||||
|
||||
UINTERFACE(BlueprintType)
|
||||
class UNREALHYPERTWIST_API UHyperTwistVisionClient : public UInterface
|
||||
{
|
||||
GENERATED_BODY()
|
||||
};
|
||||
|
||||
class UNREALHYPERTWIST_API IHyperTwistVisionClient
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
public:
|
||||
virtual bool OpenVisionSession(const FHyperTwistVisionSessionConfig& Config, FString& OutError) = 0;
|
||||
virtual FHyperTwistVisionPreviewResult SubmitVisionFrame(const FHyperTwistVisionFrameEnvelope& Frame) = 0;
|
||||
virtual FHyperTwistVisionCommitResult CommitVisionObservation(const FHyperTwistVisionCommitRequest& Request) = 0;
|
||||
virtual FHyperTwistVisionFinalizeResult FinalizeVisionSession(const FString& SessionId) = 0;
|
||||
virtual FHyperTwistVisionServiceHealth GetVisionServiceHealth() const = 0;
|
||||
};
|
||||
|
||||
UCLASS(BlueprintType)
|
||||
class UNREALHYPERTWIST_API UHyperTwistMockVisionClient : public UObject, public IHyperTwistVisionClient
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
public:
|
||||
UFUNCTION(BlueprintCallable, Category = "HyperTwist|Recognition")
|
||||
virtual bool OpenVisionSession(const FHyperTwistVisionSessionConfig& Config, FString& OutError) override;
|
||||
|
||||
UFUNCTION(BlueprintCallable, Category = "HyperTwist|Recognition")
|
||||
virtual FHyperTwistVisionPreviewResult SubmitVisionFrame(const FHyperTwistVisionFrameEnvelope& Frame) override;
|
||||
|
||||
UFUNCTION(BlueprintCallable, Category = "HyperTwist|Recognition")
|
||||
virtual FHyperTwistVisionCommitResult CommitVisionObservation(const FHyperTwistVisionCommitRequest& Request) override;
|
||||
|
||||
UFUNCTION(BlueprintCallable, Category = "HyperTwist|Recognition")
|
||||
virtual FHyperTwistVisionFinalizeResult FinalizeVisionSession(const FString& SessionId) override;
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Recognition")
|
||||
virtual FHyperTwistVisionServiceHealth GetVisionServiceHealth() const override;
|
||||
|
||||
private:
|
||||
UPROPERTY()
|
||||
TMap<FString, FHyperTwistVisionSessionConfig> SessionConfigs;
|
||||
|
||||
UPROPERTY()
|
||||
TMap<FString, int32> SessionFrameCounts;
|
||||
};
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
#pragma once
|
||||
|
||||
#include "CoreMinimal.h"
|
||||
#include "Kismet/BlueprintFunctionLibrary.h"
|
||||
#include "HyperTwistReplay/HyperTwistReplayTypes.h"
|
||||
#include "HyperTwistReplayLibrary.generated.h"
|
||||
|
||||
UCLASS()
|
||||
class UNREALHYPERTWIST_API UHyperTwistReplayLibrary : public UBlueprintFunctionLibrary
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
public:
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Replay")
|
||||
static FHyperTwistReplayPacket AppendReplayEvent(const FHyperTwistReplayPacket& Packet, const FHyperTwistReplayEvent& Event);
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Replay")
|
||||
static FHyperTwistDerivedReplaySummary DeriveReplaySummary(const FHyperTwistReplayPacket& Packet);
|
||||
};
|
||||
|
|
@ -0,0 +1,236 @@
|
|||
#pragma once
|
||||
|
||||
#include "CoreMinimal.h"
|
||||
#include "HyperTwistCore/HyperTwistCoreTypes.h"
|
||||
#include "HyperTwistReplayTypes.generated.h"
|
||||
|
||||
UENUM(BlueprintType)
|
||||
enum class EHyperTwistCaptureMode : uint8
|
||||
{
|
||||
Manual UMETA(DisplayName = "Manual"),
|
||||
Runtime UMETA(DisplayName = "Runtime"),
|
||||
Recognition UMETA(DisplayName = "Recognition"),
|
||||
SmartDevice UMETA(DisplayName = "Smart Device"),
|
||||
Imported UMETA(DisplayName = "Imported")
|
||||
};
|
||||
|
||||
UENUM(BlueprintType)
|
||||
enum class EHyperTwistReplayEventType : uint8
|
||||
{
|
||||
InspectionStart UMETA(DisplayName = "Inspection Start"),
|
||||
InspectionEnd UMETA(DisplayName = "Inspection End"),
|
||||
TimerStart UMETA(DisplayName = "Timer Start"),
|
||||
Move UMETA(DisplayName = "Move"),
|
||||
Rotation UMETA(DisplayName = "Rotation"),
|
||||
StateSnapshot UMETA(DisplayName = "State Snapshot"),
|
||||
PhaseMark UMETA(DisplayName = "Phase Mark"),
|
||||
DeviceSync UMETA(DisplayName = "Device Sync"),
|
||||
RecognitionPreview UMETA(DisplayName = "Recognition Preview"),
|
||||
RecognitionScan UMETA(DisplayName = "Recognition Scan"),
|
||||
RecognitionCommit UMETA(DisplayName = "Recognition Commit"),
|
||||
RecognitionCorrection UMETA(DisplayName = "Recognition Correction"),
|
||||
Pause UMETA(DisplayName = "Pause"),
|
||||
Resume UMETA(DisplayName = "Resume"),
|
||||
Annotation UMETA(DisplayName = "Annotation"),
|
||||
SolveEnd UMETA(DisplayName = "Solve End")
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistPhaseTiming
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString PhaseKind;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 StartedAtMs = 0;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 EndedAtMs = 0;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 DurationMs = 0;
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistDerivedReplaySummary
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 TotalTimeMs = 0;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 InspectionTimeMs = 0;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FHyperTwistPhaseTiming> PhaseTimings;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 MoveCount = 0;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
float TPS = 0.0f;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 RecognizedSegments = 0;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
float ConfidenceRollup = -1.0f;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString Result;
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistReplayEvent
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString EventId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 Sequence = 0;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 TimeMs = 0;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
EHyperTwistReplayEventType EventType = EHyperTwistReplayEventType::Annotation;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString PayloadJson;
|
||||
|
||||
bool IsStructurallyValid() const
|
||||
{
|
||||
return !EventId.IsEmpty() && Sequence > 0 && TimeMs >= 0;
|
||||
}
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistReplayPacket
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString PacketVersion = TEXT("ht-replay/v1");
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString ReplayId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistPuzzleDefinitionRef PuzzleDefinition;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
EHyperTwistCaptureMode CaptureMode = EHyperTwistCaptureMode::Runtime;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString SessionId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString StartedAtUtc;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString EndedAtUtc;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FHyperTwistReplayEvent> Events;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString SourceImportFormat;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString AnnotationsJson;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistDerivedReplaySummary DerivedSummary;
|
||||
|
||||
bool IsStructurallyValid() const
|
||||
{
|
||||
if (ReplayId.IsEmpty() || SessionId.IsEmpty() || !PuzzleDefinition.IsStructurallyValid() || Events.Num() == 0)
|
||||
{
|
||||
return false;
|
||||
}
|
||||
|
||||
int32 PreviousSequence = 0;
|
||||
for (const FHyperTwistReplayEvent& Event : Events)
|
||||
{
|
||||
if (!Event.IsStructurallyValid() || Event.Sequence <= PreviousSequence)
|
||||
{
|
||||
return false;
|
||||
}
|
||||
|
||||
PreviousSequence = Event.Sequence;
|
||||
}
|
||||
|
||||
return true;
|
||||
}
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistReplayMovePayload
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString Notation;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString TransformationRef;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString Source;
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistReplayPhaseMarkPayload
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString PhaseId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString PhaseKind;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString PhaseSource;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString PhaseAction;
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistReplayRecognitionPayload
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistStateSnapshot Snapshot;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
float Confidence = 0.0f;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString ScanStage;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString CommittedFaceOrStage;
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistReplayDeviceSyncPayload
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString DeviceKind;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString DeviceEvent;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString DevicePayloadJson;
|
||||
};
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
#pragma once
|
||||
|
||||
#include "CoreMinimal.h"
|
||||
#include "Kismet/BlueprintFunctionLibrary.h"
|
||||
#include "HyperTwistSimulation/HyperTwistSimulationTypes.h"
|
||||
#include "HyperTwistSimulationLibrary.generated.h"
|
||||
|
||||
UCLASS()
|
||||
class UNREALHYPERTWIST_API UHyperTwistSimulationLibrary : public UBlueprintFunctionLibrary
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
public:
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Simulation")
|
||||
static FHyperTwistSimulationSceneContext MakeClassicPlaceholderSceneContext();
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Simulation")
|
||||
static FHyperTwistSimulationSceneContext MakeHyperPlaceholderSceneContext();
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Simulation")
|
||||
static bool CanRenderSceneContext(const FHyperTwistSimulationSceneContext& SceneContext);
|
||||
};
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
#pragma once
|
||||
|
||||
#include "CoreMinimal.h"
|
||||
#include "HyperTwistCore/HyperTwistCoreTypes.h"
|
||||
#include "HyperTwistSimulationTypes.generated.h"
|
||||
|
||||
UENUM(BlueprintType)
|
||||
enum class EHyperTwistProjectionKind : uint8
|
||||
{
|
||||
ClassicPerspective UMETA(DisplayName = "Classic Perspective"),
|
||||
HyperProjection UMETA(DisplayName = "Hyper Projection"),
|
||||
Orthographic UMETA(DisplayName = "Orthographic")
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistProjectionSettings
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
EHyperTwistProjectionKind ProjectionKind = EHyperTwistProjectionKind::ClassicPerspective;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString ProjectionProfile = TEXT("classic-default");
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
float ProjectionDepth = 1.0f;
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistSimulationSceneContext
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString SceneContextId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistPuzzleState PuzzleState;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FHyperTwistProjectionSettings ProjectionSettings;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString RenderStateProfile;
|
||||
|
||||
bool IsStructurallyValid() const
|
||||
{
|
||||
return !SceneContextId.IsEmpty() && PuzzleState.IsStructurallyValid() && !RenderStateProfile.IsEmpty();
|
||||
}
|
||||
};
|
||||
|
|
@ -0,0 +1,67 @@
|
|||
#pragma once
|
||||
|
||||
#include "CoreMinimal.h"
|
||||
#include "Kismet/BlueprintFunctionLibrary.h"
|
||||
#include "HyperTwistTraining/HyperTwistTrainingTypes.h"
|
||||
#include "HyperTwistTrainingLibrary.generated.h"
|
||||
|
||||
UCLASS()
|
||||
class UNREALHYPERTWIST_API UHyperTwistTrainingLibrary : public UBlueprintFunctionLibrary
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
public:
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Training")
|
||||
static FHyperTwistContentPack MakeSampleClassicContentPack();
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Training")
|
||||
static bool IsTrainingCaseCompatibleWithPack(
|
||||
const FHyperTwistTrainingCase& TrainingCase,
|
||||
const FHyperTwistContentPack& ContentPack
|
||||
);
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Training")
|
||||
static bool CanStartTrainingSession(
|
||||
const FHyperTwistTrainingDeck& Deck,
|
||||
const FHyperTwistContentPack& ContentPack
|
||||
);
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Training")
|
||||
static FHyperTwistTrainingSession StartTrainingSession(
|
||||
const FHyperTwistTrainingDeck& Deck,
|
||||
const FString& UserId,
|
||||
const FString& SessionId,
|
||||
EHyperTwistTrainingDeliveryMode Mode
|
||||
);
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Training")
|
||||
static bool CanTransitionTrainingSession(
|
||||
EHyperTwistTrainingSessionState FromState,
|
||||
EHyperTwistTrainingSessionState ToState
|
||||
);
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Training")
|
||||
static FHyperTwistTrainingSession AdvanceTrainingSession(
|
||||
const FHyperTwistTrainingSession& Session,
|
||||
EHyperTwistTrainingSessionState TargetState,
|
||||
const FString& NextCaseId
|
||||
);
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Training")
|
||||
static FHyperTwistTrainingSession RecordTrainingAttempt(
|
||||
const FHyperTwistTrainingSession& Session,
|
||||
const FHyperTwistTrainingAttempt& Attempt
|
||||
);
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Training")
|
||||
static FHyperTwistTrainingSession CompleteTrainingSession(
|
||||
const FHyperTwistTrainingSession& Session,
|
||||
bool bAbortSession
|
||||
);
|
||||
|
||||
UFUNCTION(BlueprintPure, Category = "HyperTwist|Training")
|
||||
static FHyperTwistProgressionMemory MakeInitialProgressionMemory(
|
||||
const FHyperTwistTrainingSession& Session,
|
||||
const FHyperTwistTrainingCase& TrainingCase
|
||||
);
|
||||
};
|
||||
|
|
@ -0,0 +1,295 @@
|
|||
#pragma once
|
||||
|
||||
#include "CoreMinimal.h"
|
||||
#include "HyperTwistCore/HyperTwistCoreTypes.h"
|
||||
#include "HyperTwistTrainingTypes.generated.h"
|
||||
|
||||
UENUM(BlueprintType)
|
||||
enum class EHyperTwistTrainingDeliveryMode : uint8
|
||||
{
|
||||
Timer UMETA(DisplayName = "Timer"),
|
||||
VirtualCube UMETA(DisplayName = "Virtual Cube"),
|
||||
SmartDevice UMETA(DisplayName = "Smart Device"),
|
||||
RecognitionAssisted UMETA(DisplayName = "Recognition Assisted"),
|
||||
CoachReviewed UMETA(DisplayName = "Coach Reviewed")
|
||||
};
|
||||
|
||||
UENUM(BlueprintType)
|
||||
enum class EHyperTwistTrainingSelectionPolicy : uint8
|
||||
{
|
||||
Uniform UMETA(DisplayName = "Uniform"),
|
||||
Weighted UMETA(DisplayName = "Weighted"),
|
||||
Spaced UMETA(DisplayName = "Spaced"),
|
||||
Scripted UMETA(DisplayName = "Scripted")
|
||||
};
|
||||
|
||||
UENUM(BlueprintType)
|
||||
enum class EHyperTwistTrainingPromptKind : uint8
|
||||
{
|
||||
Algorithm UMETA(DisplayName = "Algorithm"),
|
||||
State UMETA(DisplayName = "State"),
|
||||
Recognition UMETA(DisplayName = "Recognition"),
|
||||
Memo UMETA(DisplayName = "Memo"),
|
||||
Sequence UMETA(DisplayName = "Sequence")
|
||||
};
|
||||
|
||||
UENUM(BlueprintType)
|
||||
enum class EHyperTwistTrainingSessionState : uint8
|
||||
{
|
||||
Created UMETA(DisplayName = "Created"),
|
||||
Ready UMETA(DisplayName = "Ready"),
|
||||
Active UMETA(DisplayName = "Active"),
|
||||
Paused UMETA(DisplayName = "Paused"),
|
||||
Reviewing UMETA(DisplayName = "Reviewing"),
|
||||
Completed UMETA(DisplayName = "Completed"),
|
||||
Aborted UMETA(DisplayName = "Aborted")
|
||||
};
|
||||
|
||||
UENUM(BlueprintType)
|
||||
enum class EHyperTwistTrainingAttemptResult : uint8
|
||||
{
|
||||
Success UMETA(DisplayName = "Success"),
|
||||
Failure UMETA(DisplayName = "Failure"),
|
||||
Timeout UMETA(DisplayName = "Timeout"),
|
||||
Aborted UMETA(DisplayName = "Aborted")
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistTrainingCase
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString CaseId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString PuzzleId = TEXT("cube/3x3x3");
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
EHyperTwistTrainingPromptKind PromptKind = EHyperTwistTrainingPromptKind::Algorithm;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString CanonicalStateRef;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString CanonicalNotation;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
float Difficulty = 0.0f;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> Tags;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<EHyperTwistTrainingDeliveryMode> AllowedDeliveryModes;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 TimeTargetMs = 0;
|
||||
|
||||
bool IsStructurallyValid() const
|
||||
{
|
||||
return !CaseId.IsEmpty() && !PuzzleId.IsEmpty();
|
||||
}
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistTrainingDeck
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString DeckId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString Title;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<EHyperTwistTrainingDeliveryMode> DeliveryModes;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
EHyperTwistTrainingSelectionPolicy SelectionPolicy = EHyperTwistTrainingSelectionPolicy::Weighted;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FHyperTwistTrainingCase> Cases;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString DifficultyBand;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FString> Tags;
|
||||
|
||||
bool IsStructurallyValid() const
|
||||
{
|
||||
return !DeckId.IsEmpty() && !Title.IsEmpty() && Cases.Num() > 0;
|
||||
}
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistTrainingTrack
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString TrackId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString Title;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString Goal;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FHyperTwistTrainingDeck> Decks;
|
||||
|
||||
bool IsStructurallyValid() const
|
||||
{
|
||||
return !TrackId.IsEmpty() && !Title.IsEmpty() && Decks.Num() > 0;
|
||||
}
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistContentPack
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString ContentPackId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString Title;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString Version = TEXT("2026.04");
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
EHyperTwistPuzzleFamily PuzzleFamily = EHyperTwistPuzzleFamily::ClassicCube;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString NotationProfile = TEXT("classic-wca");
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
TArray<FHyperTwistTrainingTrack> Tracks;
|
||||
|
||||
bool IsStructurallyValid() const
|
||||
{
|
||||
return !ContentPackId.IsEmpty() && !Title.IsEmpty() && !NotationProfile.IsEmpty() && Tracks.Num() > 0;
|
||||
}
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistTrainingSession
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString TrainingSessionId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString DeckId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString UserId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString StartedAtUtc;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString EndedAtUtc;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
EHyperTwistTrainingDeliveryMode Mode = EHyperTwistTrainingDeliveryMode::Timer;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
EHyperTwistTrainingSelectionPolicy SelectionPolicy = EHyperTwistTrainingSelectionPolicy::Weighted;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
EHyperTwistTrainingSessionState SessionState = EHyperTwistTrainingSessionState::Created;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString CurrentCaseId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 AttemptCount = 0;
|
||||
|
||||
bool IsStructurallyValid() const
|
||||
{
|
||||
return !TrainingSessionId.IsEmpty() && !DeckId.IsEmpty() && !UserId.IsEmpty();
|
||||
}
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistTrainingAttempt
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString AttemptId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString TrainingSessionId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString CaseId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
EHyperTwistTrainingAttemptResult Result = EHyperTwistTrainingAttemptResult::Failure;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 TotalTimeMs = 0;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 ExecutionTimeMs = 0;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 RecognitionTimeMs = 0;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 Mistakes = 0;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString ReplayId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString CompletedAtUtc;
|
||||
|
||||
bool IsStructurallyValid() const
|
||||
{
|
||||
return !AttemptId.IsEmpty() && !TrainingSessionId.IsEmpty() && !CaseId.IsEmpty();
|
||||
}
|
||||
};
|
||||
|
||||
USTRUCT(BlueprintType)
|
||||
struct FHyperTwistProgressionMemory
|
||||
{
|
||||
GENERATED_BODY()
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString UserId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString DeckId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString CaseId;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
float StrengthScore = 0.0f;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
FString LastSeenAtUtc;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
EHyperTwistTrainingAttemptResult LastOutcome = EHyperTwistTrainingAttemptResult::Failure;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 AttemptCount = 0;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
int32 SuccessCount = 0;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
float DifficultyWeight = 1.0f;
|
||||
|
||||
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "HyperTwist")
|
||||
float ResurfacePriority = 0.0f;
|
||||
};
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
// Copyright Epic Games, Inc. All Rights Reserved.
|
||||
|
||||
using UnrealBuildTool;
|
||||
|
||||
public class UnrealHyperTwist : ModuleRules
|
||||
{
|
||||
public UnrealHyperTwist(ReadOnlyTargetRules Target) : base(Target)
|
||||
{
|
||||
PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs;
|
||||
|
||||
PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine", "InputCore", "EnhancedInput", "Json", "JsonUtilities" });
|
||||
|
||||
PrivateDependencyModuleNames.AddRange(new string[] { });
|
||||
|
||||
// Uncomment if you are using Slate UI
|
||||
// PrivateDependencyModuleNames.AddRange(new string[] { "Slate", "SlateCore" });
|
||||
|
||||
// Uncomment if you are using online features
|
||||
// PrivateDependencyModuleNames.Add("OnlineSubsystem");
|
||||
|
||||
// To include OnlineSubsystemSteam, add it to the plugins section in your uproject file with the Enabled attribute set to true
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
// Copyright Epic Games, Inc. All Rights Reserved.
|
||||
|
||||
#include "UnrealHyperTwist.h"
|
||||
#include "Modules/ModuleManager.h"
|
||||
|
||||
IMPLEMENT_PRIMARY_GAME_MODULE( FDefaultGameModuleImpl, UnrealHyperTwist, "UnrealHyperTwist" );
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
// Copyright Epic Games, Inc. All Rights Reserved.
|
||||
|
||||
#pragma once
|
||||
|
||||
#include "CoreMinimal.h"
|
||||
|
||||
15
UnrealHyperTwist/Source/UnrealHyperTwistEditor.Target.cs
Normal file
15
UnrealHyperTwist/Source/UnrealHyperTwistEditor.Target.cs
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
// Copyright Epic Games, Inc. All Rights Reserved.
|
||||
|
||||
using UnrealBuildTool;
|
||||
using System.Collections.Generic;
|
||||
|
||||
public class UnrealHyperTwistEditorTarget : TargetRules
|
||||
{
|
||||
public UnrealHyperTwistEditorTarget( TargetInfo Target) : base(Target)
|
||||
{
|
||||
Type = TargetType.Editor;
|
||||
DefaultBuildSettings = BuildSettingsVersion.V6;
|
||||
IncludeOrderVersion = EngineIncludeOrderVersion.Unreal5_7;
|
||||
ExtraModuleNames.Add("UnrealHyperTwist");
|
||||
}
|
||||
}
|
||||
26
UnrealHyperTwist/UnrealHyperTwist.uproject
Normal file
26
UnrealHyperTwist/UnrealHyperTwist.uproject
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
{
|
||||
"FileVersion": 3,
|
||||
"EngineAssociation": "5.7",
|
||||
"Category": "",
|
||||
"Description": "",
|
||||
"Modules": [
|
||||
{
|
||||
"Name": "UnrealHyperTwist",
|
||||
"Type": "Runtime",
|
||||
"LoadingPhase": "Default"
|
||||
}
|
||||
],
|
||||
"Plugins": [
|
||||
{
|
||||
"Name": "ModelingToolsEditorMode",
|
||||
"Enabled": true,
|
||||
"TargetAllowList": [
|
||||
"Editor"
|
||||
]
|
||||
},
|
||||
{
|
||||
"Name": "RemoteControl",
|
||||
"Enabled": true
|
||||
}
|
||||
]
|
||||
}
|
||||
100
docs/Deepseek C# Prompt
Normal file
100
docs/Deepseek C# Prompt
Normal file
|
|
@ -0,0 +1,100 @@
|
|||
Role: Principal Software Engineer at a AAA Game Studio, building tooling for Unreal Engine 5.
|
||||
Project: VR Codebase Inspector and Security Pen-Testing Analyzer.
|
||||
Architecture: Unreal Engine 5 (C++ Client) <---WebSocket---> C# .NET 8 Backend Analysis Server.
|
||||
Constraint: The C# server runs on a local workstation (or cloud VM) alongside the VR headset. It must process arbitrary open-source codebases (C++, C#, Python, JS) and return JSON graphs of vulnerabilities and call hierarchies.
|
||||
|
||||
Technical Directives (To Prevent AI Model Degradation into .NET Framework patterns):
|
||||
1. AOT Compatibility: This server may eventually run inside a Docker container with `-p:PublishAot=true`. Therefore, YOU CANNOT USE REFLECTION (`GetProperties()`, `GetMethods()`). All type scanning MUST use **Roslyn Source Generators** OR **Microsoft.CodeAnalysis** (Compilation APIs) which are AOT-safe.
|
||||
2. Roslyn Analyzer: Write a C# Script that uses `Microsoft.CodeAnalysis.CSharp` to parse a given folder of C# code and return a list of `UnsafeMethodCall` objects (e.g., `Process.Start` usage, `DllImport` attributes). YOU MUST PROVIDE A `Solution` file and `Project` loader that handles `AdhocWorkspace`.
|
||||
3. C++ Parsing: For the Unreal side, DO NOT attempt to wrap Unreal C++ in C#. Instead, C# will shell out to `clang-tidy` or `cppcheck`. Show me the `Process` spawning logic with **OutputDataReceived** event handlers that send progress updates back to the client via SignalR.
|
||||
4. Performance: Use `System.IO.Pipelines` (PipeReader) to stream massive source files (e.g., 100MB `Intermediate/Build/Source.cpp`) without allocating huge strings on the Large Object Heap.
|
||||
5. Frontend Interop: Generate a TypeScript client definition from the C# SignalR hub using `@microsoft/signalr-protocol-msgpack`. Include the command for `nswag` or `openapi-generator`.
|
||||
|
||||
Output Expected:
|
||||
1. A detailed architecture diagram in Mermaid format.
|
||||
2. The C# code for `RoslynAnalyzerService.cs` and `CppAnalyzerService.cs`.
|
||||
3. Explanation of how to handle the **Impedance Mismatch**: C# wants deterministic disposal, Unreal expects persistent open sockets. How will you manage lifetime of the WebSocket connection?
|
||||
4. A note on **Security**: This tool will be used for pen-testing. The C# server executes untrusted user scripts (via shell). Provide the `ProcessStartInfo` configuration to ensure **Sandboxing** (e.g., `UseShellExecute=false`, `WorkingDirectory` restriction, `EnvironmentVariables` scrub).
|
||||
|
||||
Continue generating the response now. Provide full code blocks, do not use placeholders like "// logic here". Be explicit.
|
||||
|
||||
---
|
||||
|
||||
Role: Senior systems architect for math-heavy multiplayer applications with Unreal frontends and C# backend services.
|
||||
|
||||
Project: Hypercubing virtual reality application. Unreal will render and handle immersive interaction. C# is being considered for simulation, multiplayer backend, persistence, telemetry, and orchestration.
|
||||
|
||||
Objective: Design a high-performance architecture where Unreal remains the client/runtime and C# owns the durable and computational service layer.
|
||||
|
||||
Hard constraints:
|
||||
1. Do not propose replacing Unreal gameplay/runtime with C#.
|
||||
2. Use C# for:
|
||||
- simulation services where server authority is needed
|
||||
- session state
|
||||
- matchmaking
|
||||
- persistence
|
||||
- replay/event logs
|
||||
- analytics
|
||||
- user/session/account services
|
||||
- collaboration or shared puzzle state
|
||||
3. Assume the math may become non-trivial and should remain strongly typed and testable.
|
||||
4. Prefer explicit contracts and deterministic state transitions.
|
||||
5. No reflection-driven architecture in core simulation paths.
|
||||
6. Design for low-latency updates, reconnect, state recovery, and versioned protocol evolution.
|
||||
7. Assume future scale from single-user local mode up to networked synchronized sessions.
|
||||
|
||||
Deliverables:
|
||||
- Service layout
|
||||
- Unreal-to-backend communication model
|
||||
- State authority model
|
||||
- Sync strategy
|
||||
- Persistence model
|
||||
- Replay/event sourcing recommendation
|
||||
- Math/simulation placement
|
||||
- Testing strategy for deterministic correctness
|
||||
- Deployment options from local to hosted
|
||||
- AI-assisted development constraints for C# code generation on this project
|
||||
|
||||
If output is interrupted, continue from the exact next unfinished section. Do not summarize. Continue raw technical output only.
|
||||
|
||||
---
|
||||
|
||||
Role: Senior architect for C# backends and Unreal-integrated systems.
|
||||
|
||||
Project: Virtual reality codebase inspector and pentest platform. Unreal is the client/runtime. C# is being considered for backend, analysis, orchestration, collaboration, and data services.
|
||||
|
||||
Objective: Design the system so Unreal remains responsible for rendering and interaction, while C# owns the heavy platform logic.
|
||||
|
||||
Hard constraints:
|
||||
1. Do not propose writing Unreal gameplay code in C#.
|
||||
2. Treat Unreal as C++/Blueprint client only.
|
||||
3. Use C# for:
|
||||
- repository ingestion
|
||||
- graph/index building
|
||||
- code intelligence
|
||||
- plugin and tool orchestration
|
||||
- pentest job scheduling
|
||||
- evidence storage
|
||||
- collaboration services
|
||||
- multiplayer/session backend
|
||||
4. The system must support polyglot repositories and external scanners written in many languages.
|
||||
5. Prefer out-of-process boundaries, gRPC/HTTP/WebSocket boundaries, or worker sandbox boundaries over in-process interop.
|
||||
6. No reflection-heavy magic in core runtime paths.
|
||||
7. Assume large repos, long-running scans, and untrusted tool output.
|
||||
8. Design for cancellation, resumability, auditability, and multi-tenant isolation.
|
||||
|
||||
Deliverables:
|
||||
- Full architecture with Unreal placement and C# placement
|
||||
- Recommended service decomposition
|
||||
- Worker sandbox strategy
|
||||
- Plugin execution strategy
|
||||
- Security boundaries for pentest tooling
|
||||
- Repository indexing pipeline
|
||||
- Real-time event streaming into VR
|
||||
- Storage model for findings, graphs, evidence, and sessions
|
||||
- Auth model and operator roles
|
||||
- Queueing and scheduling design
|
||||
- Deployment topology for local workstation, single VPS, and larger multi-node setups
|
||||
- AI integration boundaries and safe prompting strategy for code and security tasks
|
||||
|
||||
If output is interrupted, continue exactly where you stopped. Do not summarize. Output the remaining architecture in the same level of detail.
|
||||
592
docs/EXTERNAL_MIRROR_WORKSPACE_AND_SUBMODULE_HANDOFF.md
Normal file
592
docs/EXTERNAL_MIRROR_WORKSPACE_AND_SUBMODULE_HANDOFF.md
Normal file
|
|
@ -0,0 +1,592 @@
|
|||
# External Mirror Workspace And Submodule Handoff
|
||||
|
||||
Created on `2026-04-23`
|
||||
|
||||
## Purpose
|
||||
|
||||
This document defines the operating model for large repository fleets across:
|
||||
|
||||
- `C:\ScriptoriumAI`
|
||||
- `C:\HyperTwist`
|
||||
- `C:\VectorShell`
|
||||
|
||||
The goal is to keep:
|
||||
|
||||
- first-party product repos clean
|
||||
- external research mirrors discoverable
|
||||
- restrictive-source custody legally defensible
|
||||
- clean-room handoff repeatable across sessions and models
|
||||
|
||||
This document is intentionally written as a handoff artifact, not just a local memo. Another model or operator should be able to pick it up later and understand:
|
||||
|
||||
- where mirrors live
|
||||
- which mirrors are safe for direct donor work
|
||||
- which mirrors are `Model A only`
|
||||
- where scrubbed clean-room artifacts belong
|
||||
- where `Model B` implementation work is allowed to happen
|
||||
|
||||
Related boundary document:
|
||||
|
||||
- for explicit clean-room `Model B` source restrictions, also read `docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md`
|
||||
|
||||
## Core decision
|
||||
|
||||
Do not place large mirror fleets inside the main product repos.
|
||||
|
||||
That creates avoidable problems:
|
||||
|
||||
- nested Git complexity
|
||||
- slower backup and sync behavior
|
||||
- noisy file watchers
|
||||
- heavier IDE indexing
|
||||
- larger `.vs` state
|
||||
- harder solution and agent-context management
|
||||
- slower global search over mixed first-party and third-party trees
|
||||
- weaker legal separation for restrictive-source work
|
||||
|
||||
Instead, use one external workspace root per product.
|
||||
|
||||
## Current safe setup
|
||||
|
||||
The live repos remain where they are today:
|
||||
|
||||
- `C:\ScriptoriumAI`
|
||||
- `C:\HyperTwist`
|
||||
- `C:\VectorShell`
|
||||
|
||||
The external workspace scaffold exists separately under:
|
||||
|
||||
- `C:\Workspaces\ScriptoriumAI`
|
||||
- `C:\Workspaces\HyperTwist`
|
||||
- `C:\Workspaces\VectorShell`
|
||||
|
||||
This is deliberate.
|
||||
|
||||
Important constraint:
|
||||
|
||||
- the live repos were **not** moved into `app\` yet
|
||||
- `app\` remains a documented future migration target
|
||||
- generated artifacts point to the current live repo paths unless and until an explicit migration is approved
|
||||
|
||||
## Why the workspace model now needs a custody split
|
||||
|
||||
A simple external `mirrors\` folder is not enough once restrictive repos enter the process.
|
||||
|
||||
Two different workflows must be kept separate:
|
||||
|
||||
1. Direct donor or normal source-audit work
|
||||
2. Restrictive-source clean-room or benchmark-oracle work
|
||||
|
||||
If both workflows share the same undifferentiated mirror area, later handoff becomes ambiguous.
|
||||
|
||||
That ambiguity is exactly what causes trouble when:
|
||||
|
||||
- a GPL repo is mistaken for a donor
|
||||
- an all-rights-reserved repo is later seen by an implementation model
|
||||
- a no-license repo is treated as if mirroring alone made it reusable
|
||||
- a benchmark solver is confused with a clean-room implementation target
|
||||
|
||||
The workspace therefore now needs explicit separation between:
|
||||
|
||||
- permissive mirrors
|
||||
- restrictive mirrors
|
||||
- scrubbed clean-room handoff artifacts
|
||||
- isolated implementation workspaces
|
||||
|
||||
## Folder model
|
||||
|
||||
Each product workspace now follows this structure:
|
||||
|
||||
```text
|
||||
C:\Workspaces\<Product>\
|
||||
app\ <- reserved future landing zone for the first-party repo
|
||||
mirrors\
|
||||
permissive\ <- MIT / Apache / BSD / acceptable donor mirrors
|
||||
restrictive\ <- GPL / no-license / all-rights-reserved mirrors
|
||||
clean-room-specs\ <- scrubbed Model A outputs safe for Model B handoff
|
||||
implementation-workspaces\
|
||||
model-b\ <- isolated implementation area; must not read restrictive mirrors
|
||||
scratch\ <- temporary safe experiments that are not authoritative
|
||||
generated\ <- generated solutions and solution filters
|
||||
cache\ <- clone cache, bare mirrors, temp sync state, generated lookup data
|
||||
repos.manifest.json
|
||||
README.md
|
||||
.gitignore
|
||||
```
|
||||
|
||||
## Meaning of each root
|
||||
|
||||
### `app\`
|
||||
|
||||
This is a future migration target only.
|
||||
|
||||
Current rule:
|
||||
|
||||
- do not move the live repo here implicitly
|
||||
- do not treat its existence as proof that migration has already happened
|
||||
|
||||
### `mirrors\permissive\`
|
||||
|
||||
Use this root for repos that are currently acceptable for normal source reading and donor evaluation, such as:
|
||||
|
||||
- MIT
|
||||
- Apache-2.0
|
||||
- BSD
|
||||
- dual-permissive combinations
|
||||
|
||||
These mirrors may support:
|
||||
|
||||
- code-level donor review
|
||||
- direct integration analysis
|
||||
- adapter planning
|
||||
- ordinary implementation work if the final legal posture remains acceptable
|
||||
|
||||
### `mirrors\restrictive\`
|
||||
|
||||
Use this root for repos that are not safe for ordinary code-reuse workflows, such as:
|
||||
|
||||
- GPL / AGPL / LGPL where direct use is not intended
|
||||
- no-license repos
|
||||
- all-rights-reserved repos
|
||||
- any repo with unresolved or contested licensing
|
||||
|
||||
Critical rule:
|
||||
|
||||
- this root is `Model A only`
|
||||
- a clean-room `Model B` must not read source from here
|
||||
|
||||
### `clean-room-specs\`
|
||||
|
||||
This root is the safe handoff zone between exposed and unexposed work.
|
||||
|
||||
Expected contents:
|
||||
|
||||
- scrubbed behavior specifications
|
||||
- black-box architecture notes
|
||||
- acceptance tests
|
||||
- no-copy guardrails
|
||||
- benchmark-oracle usage notes
|
||||
|
||||
This root is what `Model B` may safely consume.
|
||||
|
||||
### `implementation-workspaces\model-b\`
|
||||
|
||||
This is the isolated clean-room implementation surface.
|
||||
|
||||
Rules:
|
||||
|
||||
- do not clone restrictive mirrors here
|
||||
- do not mount restrictive paths here
|
||||
- do not use a session that already read restrictive source here
|
||||
- use only scrubbed handoff artifacts from `clean-room-specs\`
|
||||
|
||||
### `implementation-workspaces\scratch\`
|
||||
|
||||
Use this for:
|
||||
|
||||
- temporary experiments
|
||||
- local validation harnesses
|
||||
- rough working notes
|
||||
|
||||
Do not treat it as long-term source of truth.
|
||||
|
||||
## Manifest control plane
|
||||
|
||||
Each workspace root contains:
|
||||
|
||||
- `repos.manifest.json`
|
||||
|
||||
This file is the control plane for:
|
||||
|
||||
- repository inventory
|
||||
- mirror class
|
||||
- workflow role
|
||||
- legal posture
|
||||
- source exposure rules
|
||||
- generated solution artifacts
|
||||
|
||||
Ad hoc clone folders are not the authority.
|
||||
|
||||
The manifest is.
|
||||
|
||||
## Manifest schema
|
||||
|
||||
Current schema version:
|
||||
|
||||
- `2`
|
||||
|
||||
Top-level structure:
|
||||
|
||||
```json
|
||||
{
|
||||
"schemaVersion": 2,
|
||||
"productName": "HyperTwist",
|
||||
"generatedAtUtc": "...",
|
||||
"workspace": {
|
||||
"workspaceRoot": "...",
|
||||
"currentAppRoot": "...",
|
||||
"plannedAppRoot": "...",
|
||||
"mirrorsRoot": "...",
|
||||
"permissiveMirrorsRoot": "...",
|
||||
"restrictiveMirrorsRoot": "...",
|
||||
"cleanRoomSpecsRoot": "...",
|
||||
"implementationWorkspacesRoot": "...",
|
||||
"modelBWorkspacesRoot": "...",
|
||||
"scratchWorkspacesRoot": "...",
|
||||
"generatedRoot": "...",
|
||||
"cacheRoot": "..."
|
||||
},
|
||||
"policy": {
|
||||
"defaultIncludeMode": "root",
|
||||
"restrictiveMirrorsModelAOnly": true,
|
||||
"modelBMayReadRestrictiveMirrors": false,
|
||||
"benchmarkOracleDefaultUsage": "...",
|
||||
"cleanRoomDefaultUsage": "..."
|
||||
},
|
||||
"repositories": [
|
||||
{
|
||||
"key": "...",
|
||||
"name": "...",
|
||||
"repoUrl": "...",
|
||||
"localPath": "...",
|
||||
"purpose": "...",
|
||||
"language": "...",
|
||||
"includeMode": "root",
|
||||
"storage": "external-mirror",
|
||||
"license": "...",
|
||||
"licenseStatus": "...",
|
||||
"mirrorClass": "permissive|restrictive|in-repo|app-repo",
|
||||
"workflowRole": "...",
|
||||
"modelAAllowedSourceAccess": true,
|
||||
"modelBAllowedSourceAccess": false,
|
||||
"handoffDoc": "...",
|
||||
"notes": []
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Repository fields that matter operationally
|
||||
|
||||
### `storage`
|
||||
|
||||
Allowed meanings:
|
||||
|
||||
- `app-repo`
|
||||
- `submodule`
|
||||
- `external-mirror`
|
||||
|
||||
### `mirrorClass`
|
||||
|
||||
Allowed meanings:
|
||||
|
||||
- `app-repo`
|
||||
- `in-repo`
|
||||
- `permissive`
|
||||
- `restrictive`
|
||||
|
||||
### `workflowRole`
|
||||
|
||||
Examples:
|
||||
|
||||
- `first-party`
|
||||
- `pinned-dependency`
|
||||
- `foundation-donor`
|
||||
- `parallel-foundation-donor`
|
||||
- `strategic-donor`
|
||||
- `focused-donor`
|
||||
- `training-bench`
|
||||
- `reference-donor`
|
||||
- `reference-only`
|
||||
- `clean-room-candidate`
|
||||
- `benchmark-oracle`
|
||||
|
||||
These roles are operational and architectural. They are not just labels.
|
||||
|
||||
### `modelAAllowedSourceAccess`
|
||||
|
||||
This answers:
|
||||
|
||||
- may the exposed analysis side read this source directly?
|
||||
|
||||
### `modelBAllowedSourceAccess`
|
||||
|
||||
This answers:
|
||||
|
||||
- may the isolated implementation side read this source directly?
|
||||
|
||||
For restrictive mirrors, this should be:
|
||||
|
||||
- `false`
|
||||
|
||||
### `handoffDoc`
|
||||
|
||||
Use this for:
|
||||
|
||||
- repo-specific clean-room dossier
|
||||
- benchmark-oracle guidance
|
||||
- or any durable handoff note another model should read before touching the repo’s outputs
|
||||
|
||||
Operational rule:
|
||||
|
||||
- for `restrictive` mirrors, `handoffDoc` should point to a workspace-safe file under `clean-room-specs\`
|
||||
- do not point `handoffDoc` at raw exposed-side research notes if those notes contain source breadcrumbs, protected file paths, or other Model A-only material
|
||||
- raw parse folders may remain useful for exposed-side continuity, but the manifest should direct later implementation work to the scrubbed handoff zone instead
|
||||
|
||||
## Generated artifacts
|
||||
|
||||
Each workspace writes:
|
||||
|
||||
- `generated\main.sln`
|
||||
- `generated\catalog.sln`
|
||||
- `generated\active.slnf`
|
||||
|
||||
### `main.sln`
|
||||
|
||||
Purpose:
|
||||
|
||||
- first-party code
|
||||
- current app projects
|
||||
- active pinned integrations represented as lightweight folders when they are not directly loadable projects
|
||||
|
||||
### `catalog.sln`
|
||||
|
||||
Purpose:
|
||||
|
||||
- high-level discoverability
|
||||
- workspace config visibility
|
||||
- permissive and restrictive mirror group visibility
|
||||
- clean-room handoff doc visibility
|
||||
|
||||
This is intentionally light. It is not a promise that every mirror is safe to open or edit casually.
|
||||
|
||||
### `active.slnf`
|
||||
|
||||
Purpose:
|
||||
|
||||
- fast working-set entry point
|
||||
- points to `main.sln`
|
||||
- limits the default IDE surface to the current core projects
|
||||
|
||||
## Submodule policy
|
||||
|
||||
Submodules are still valid, but only for mirrors that truly need to stay pinned inside the product repo.
|
||||
|
||||
Keep submodules when all of these are true:
|
||||
|
||||
- the product depends on the mirror by path
|
||||
- the revision must stay pinned in the main repo
|
||||
- CI or deployment needs the repo to exist inside the product tree
|
||||
|
||||
Do not use submodules as a substitute for the external workspace.
|
||||
|
||||
### Practical consequences of submodules
|
||||
|
||||
- the parent repo stores a commit pointer, not the contents directly
|
||||
- clone and bootstrap require submodule initialization
|
||||
- editing happens inside the submodule repo first, then the parent repo records the new SHA
|
||||
|
||||
Useful commands:
|
||||
|
||||
```powershell
|
||||
git clone --recurse-submodules <repo>
|
||||
git submodule sync --recursive
|
||||
git submodule update --init --recursive
|
||||
```
|
||||
|
||||
## External mirror policy
|
||||
|
||||
Use external mirrors for:
|
||||
|
||||
- large repo intake queues
|
||||
- research and evaluation mirrors
|
||||
- repos that are visible but not actively edited
|
||||
- repos that should not bloat the product repo
|
||||
- restrictive-source custody
|
||||
- benchmark-oracle custody
|
||||
|
||||
Mirror repos by:
|
||||
|
||||
- owner
|
||||
- repo
|
||||
|
||||
Example:
|
||||
|
||||
```text
|
||||
C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube
|
||||
C:\Workspaces\HyperTwist\mirrors\restrictive\AviKaufman\Rubix-cube-trainer
|
||||
```
|
||||
|
||||
## Benchmark oracle vs clean-room implementation
|
||||
|
||||
These are not the same thing.
|
||||
|
||||
### Benchmark oracle
|
||||
|
||||
A benchmark oracle is a repo you keep primarily for:
|
||||
|
||||
- correctness comparison
|
||||
- regression checks
|
||||
- move-optimality comparison
|
||||
- expected-output generation
|
||||
- performance baselining
|
||||
- acceptance-test generation
|
||||
|
||||
A benchmark oracle does **not** automatically imply:
|
||||
|
||||
- code reuse
|
||||
- direct integration
|
||||
- current clean-room reimplementation
|
||||
|
||||
Example:
|
||||
|
||||
- an optimal GPL solver can be valuable as a correctness oracle without becoming a current clean-room target
|
||||
|
||||
### Clean-room implementation candidate
|
||||
|
||||
A clean-room candidate is a restrictive repo whose **behavior or architecture** is valuable enough that you want a first-party implementation later, but with source separation.
|
||||
|
||||
That requires:
|
||||
|
||||
1. exposed `Model A` source reading
|
||||
2. scrubbed handoff artifacts
|
||||
3. isolated `Model B` implementation with no source access
|
||||
|
||||
### Rule of thumb
|
||||
|
||||
Use `benchmark-oracle` when the repo’s main value is:
|
||||
|
||||
- proving whether your result is correct
|
||||
- proving whether your solver or planner is good enough
|
||||
|
||||
Use `clean-room-candidate` when the repo’s main value is:
|
||||
|
||||
- a user-facing product behavior
|
||||
- a planner/state architecture pattern
|
||||
- a lesson flow or practice flow worth rebuilding first-party
|
||||
|
||||
## Commands
|
||||
|
||||
Initialize all three workspaces:
|
||||
|
||||
```powershell
|
||||
powershell -ExecutionPolicy Bypass -File C:\HyperTwist\scripts\Initialize-ExternalProductWorkspace.ps1 -Product All
|
||||
```
|
||||
|
||||
Refresh manifests from the baked-in defaults:
|
||||
|
||||
```powershell
|
||||
powershell -ExecutionPolicy Bypass -File C:\HyperTwist\scripts\Initialize-ExternalProductWorkspace.ps1 -Product All -ForceManifestRefresh
|
||||
```
|
||||
|
||||
Initialize a single product:
|
||||
|
||||
```powershell
|
||||
powershell -ExecutionPolicy Bypass -File C:\VectorShell\scripts\Initialize-ExternalProductWorkspace.ps1 -Product VectorShell
|
||||
```
|
||||
|
||||
Mirror every external repo listed in a manifest:
|
||||
|
||||
```powershell
|
||||
$manifest = Get-Content -Raw C:\Workspaces\HyperTwist\repos.manifest.json | ConvertFrom-Json
|
||||
$repos = $manifest.repositories | Where-Object { $_.storage -eq 'external-mirror' -and -not [string]::IsNullOrWhiteSpace($_.repoUrl) }
|
||||
foreach ($repo in $repos) {
|
||||
$parent = Split-Path -Path $repo.localPath -Parent
|
||||
if (-not (Test-Path -LiteralPath $parent)) {
|
||||
New-Item -ItemType Directory -Path $parent -Force | Out-Null
|
||||
}
|
||||
|
||||
if (-not (Test-Path -LiteralPath $repo.localPath)) {
|
||||
git clone --depth 1 $repo.repoUrl $repo.localPath
|
||||
} else {
|
||||
git -C $repo.localPath fetch --all --tags --prune
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Validate the generated roots quickly:
|
||||
|
||||
```powershell
|
||||
Test-Path C:\Workspaces\HyperTwist\mirrors\permissive
|
||||
Test-Path C:\Workspaces\HyperTwist\mirrors\restrictive
|
||||
Test-Path C:\Workspaces\HyperTwist\clean-room-specs
|
||||
Test-Path C:\Workspaces\HyperTwist\implementation-workspaces\model-b
|
||||
Test-Path C:\Workspaces\HyperTwist\generated\main.sln
|
||||
Test-Path C:\Workspaces\HyperTwist\generated\catalog.sln
|
||||
Test-Path C:\Workspaces\HyperTwist\generated\active.slnf
|
||||
```
|
||||
|
||||
## Product notes
|
||||
|
||||
### ScriptoriumAI
|
||||
|
||||
Current stance:
|
||||
|
||||
- external workspace scaffold exists
|
||||
- app remains in `C:\ScriptoriumAI`
|
||||
- pinned in-repo submodules remain where they already live
|
||||
|
||||
The submodule set still includes the retained pinned repos discussed earlier, while the external workspace is the place for future non-pinned mirror fleets.
|
||||
|
||||
### HyperTwist
|
||||
|
||||
Current stance:
|
||||
|
||||
- external workspace scaffold exists
|
||||
- app remains in `C:\HyperTwist`
|
||||
- the discussed HyperTwist repo set should live in the external workspace and be split between permissive and restrictive roots
|
||||
|
||||
HyperTwist is the strongest current need for restrictive-source custody because it already contains:
|
||||
|
||||
- permissive donors
|
||||
- GPL benchmarks
|
||||
- no-license repos
|
||||
- all-rights-reserved pedagogy references
|
||||
|
||||
### VectorShell
|
||||
|
||||
Current stance:
|
||||
|
||||
- external workspace scaffold exists
|
||||
- app remains in `C:\VectorShell`
|
||||
- app-only by default for now
|
||||
|
||||
If VectorShell later needs a broad mirror fleet, the same permissive/restrictive split should be used from the start.
|
||||
|
||||
## Recommended workflow
|
||||
|
||||
1. Add or review candidate repos in the manifest, not ad hoc in the product repo.
|
||||
2. Default new candidates to `external-mirror` plus `root`.
|
||||
3. Classify each mirror as `permissive` or `restrictive` immediately.
|
||||
4. Mark each repo’s `workflowRole` explicitly.
|
||||
5. Keep restrictive mirrors out of `Model B` workspaces.
|
||||
6. Produce repo-specific `Model A` handoff docs for clean-room candidates.
|
||||
7. Use restrictive benchmark repos as oracles where needed, but do not confuse that with implementation approval.
|
||||
8. Re-run the workspace script after changing manifest defaults or project file maps.
|
||||
|
||||
## What this setup does not do
|
||||
|
||||
It does not automatically:
|
||||
|
||||
- move the live repos into `app\`
|
||||
- decide your long-term licensing strategy
|
||||
- make restrictive repos safe for direct reuse
|
||||
- decide which benchmarks deserve later clean-room implementation
|
||||
- remove the need for deliberate handoff discipline
|
||||
|
||||
Those remain deliberate follow-up choices.
|
||||
|
||||
## Handoff summary
|
||||
|
||||
If another model picks this up later, the key facts are:
|
||||
|
||||
- external workspaces are scaffolded for all three products
|
||||
- live repos were intentionally left in place
|
||||
- `app\` is a future migration target only
|
||||
- `repos.manifest.json` is the control plane
|
||||
- permissive and restrictive mirrors are now separate by design
|
||||
- restrictive mirrors are `Model A only`
|
||||
- `clean-room-specs\` is the safe handoff zone
|
||||
- `implementation-workspaces\model-b\` is the isolated implementation zone
|
||||
- benchmark oracles and clean-room candidates must not be conflated
|
||||
- large future repo fleets should go to `C:\Workspaces\<Product>\mirrors`, not into the product repos themselves
|
||||
144
docs/MIRROR_KEEP_VS_MOVE_OUT_EVALUATION.md
Normal file
144
docs/MIRROR_KEEP_VS_MOVE_OUT_EVALUATION.md
Normal file
|
|
@ -0,0 +1,144 @@
|
|||
# Mirror Keep Versus Move Out Evaluation
|
||||
|
||||
## Status
|
||||
|
||||
This is an evaluation document, not a removal order.
|
||||
|
||||
Unless already explicitly removed in a prior cleanup pass, the mirrors discussed below are to be retained for now pending review with other models.
|
||||
|
||||
## Scope
|
||||
|
||||
This evaluation applies to the current `C:\ScriptoriumAI\mirrors` inventory and the product-adjacent mirrors under `C:\ScriptoriumAI\scriptoriumai-ui\mirrors`.
|
||||
|
||||
Already removed in the prior cleanup pass:
|
||||
|
||||
- `mirrors/claude-prism`
|
||||
- `mirrors/zotero`
|
||||
- `scriptoriumai-ui/mirrors/GitNexus`
|
||||
- `Overleaf/overleaf`
|
||||
- `Overleaf/overleaf-main`
|
||||
|
||||
## Evaluation Method
|
||||
|
||||
The classification below is based on:
|
||||
|
||||
- direct path-based references in the active app, server, scripts, and service code
|
||||
- whether the mirror is a true pinned runtime or build dependency
|
||||
- whether the mirror is only used as inspiration, examples, or internal tooling
|
||||
- whether the mirror looks like a large intake candidate better suited to an external workspace
|
||||
|
||||
## Keep In Repo
|
||||
|
||||
These are the mirrors that still make sense as in-repo pinned dependencies.
|
||||
|
||||
### High-confidence keep
|
||||
|
||||
- `mirrors/GitNexus`
|
||||
- `mirrors/claude-skills`
|
||||
- `mirrors/awesome-claude-skills`
|
||||
- `mirrors/latexocr`
|
||||
- `mirrors/pdfdelta`
|
||||
- `mirrors/pdfmd`
|
||||
- `mirrors/code2video`
|
||||
- `mirrors/paper2video`
|
||||
- `mirrors/liquid-glass-react`
|
||||
|
||||
### Why they stay
|
||||
|
||||
- `GitNexus` remains the retained internal code-intelligence tool and the root copy is the correct one to keep.
|
||||
- `claude-skills` and `awesome-claude-skills` remain tied to the skills-management workflow.
|
||||
- `latexocr` remains path-wired into the OCR service and Docker build.
|
||||
- `pdfdelta` and `pdfmd` remain tied to the PDF intake and diffing flows.
|
||||
- `code2video` and `paper2video` remain wired into server services.
|
||||
- `liquid-glass-react` remains a pinned donor for the glass UI implementation.
|
||||
|
||||
## Move Out Candidates
|
||||
|
||||
These are the mirrors that look better as external workspace mirrors than as in-repo submodules.
|
||||
|
||||
### Highest-confidence move-out candidates
|
||||
|
||||
- `mirrors/fabro`
|
||||
- `mirrors/litellm`
|
||||
- `mirrors/open-webui`
|
||||
- `mirrors/OpenSpace`
|
||||
- `mirrors/ReMe`
|
||||
- `mirrors/Roo-Code`
|
||||
- `mirrors/skillhub`
|
||||
- `mirrors/smriti`
|
||||
- `mirrors/supermemory`
|
||||
|
||||
### Why they are candidates
|
||||
|
||||
- In the active code scan they only showed up in mirror-sync automation or similarly shallow references.
|
||||
- They do not currently present as pinned path dependencies of the shipping product.
|
||||
- They fit better as external research, evaluation, or optional integration repos.
|
||||
|
||||
## Likely Move Out Candidates
|
||||
|
||||
These do not currently justify living inside the main repo, but the evidence is weaker than the group above because some of them inform UI concepts or feature directions.
|
||||
|
||||
- `mirrors/cheatsheet`
|
||||
- `mirrors/veritas-kanban`
|
||||
- `mirrors/paper2all`
|
||||
- `mirrors/featurebase`
|
||||
- `mirrors/itshover`
|
||||
- `mirrors/mind-map`
|
||||
- `mirrors/next-ai-draw-io`
|
||||
- `mirrors/paperbanana`
|
||||
- `mirrors/remotion`
|
||||
- `mirrors/storm`
|
||||
- `mirrors/supertokens-auth-react`
|
||||
- `mirrors/excalidraw`
|
||||
|
||||
### Why they are not automatic keeps
|
||||
|
||||
- Several are only referenced by inspiration comments, examples, or visual donor notes.
|
||||
- Several appear conceptually relevant but not directly path-wired into current runtime logic.
|
||||
- These are good external workspace candidates unless a later pass proves they need pinned in-repo revisions.
|
||||
|
||||
## Large Cluster Best Moved Outside
|
||||
|
||||
The following family should almost certainly be managed as external mirrors rather than in-repo mirrors unless there is a very specific active editing reason:
|
||||
|
||||
- `mirrors/chanim`
|
||||
- `mirrors/manim`
|
||||
- every `mirrors/manim-*` entry
|
||||
- every `mirrors/Manim*` entry
|
||||
|
||||
### Why
|
||||
|
||||
- The cluster is broad and repo-heavy.
|
||||
- The active product does not currently justify keeping the entire family pinned inside the main repo.
|
||||
- This is exactly the kind of fleet that benefits from the external workspace model.
|
||||
|
||||
## Current Decision
|
||||
|
||||
The current operating decision is:
|
||||
|
||||
- keep the existing retained mirrors in place for now
|
||||
- do not promote more in-repo mirrors casually
|
||||
- direct future intake toward the external workspace roots
|
||||
- revisit each move-out candidate only when there is a concrete integration or editing need
|
||||
|
||||
## Practical Rule Going Forward
|
||||
|
||||
Use this rule for new mirror decisions:
|
||||
|
||||
Keep a mirror in-repo only if all three are true:
|
||||
|
||||
- the product depends on it by path
|
||||
- the revision must be pinned inside the product repo
|
||||
- CI or deployment depends on that exact in-repo location
|
||||
|
||||
Otherwise:
|
||||
|
||||
- move or add it to `C:\Workspaces\ScriptoriumAI\mirrors`
|
||||
- track it in `C:\Workspaces\ScriptoriumAI\repos.manifest.json`
|
||||
- leave it in `root` include mode until active editing justifies promotion
|
||||
|
||||
## Handoff Note
|
||||
|
||||
This file is intentionally conservative.
|
||||
|
||||
It records what looks safe to keep, what looks safe to move out, and what should remain undecided until another review round. The aim is to preserve optionality while preventing the main repo from turning into a permanent warehouse for every interesting upstream project.
|
||||
37
docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md
Normal file
37
docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md
Normal file
|
|
@ -0,0 +1,37 @@
|
|||
# Model B Source Access Boundary
|
||||
|
||||
Created on `2026-04-23`
|
||||
|
||||
Purpose:
|
||||
|
||||
- make the clean-room `Model B` boundary explicit for HyperTwist work
|
||||
- prevent accidental reading of restrictive mirrors or unrelated sensitive ops material
|
||||
|
||||
## Allowed for clean-room `Model B`
|
||||
|
||||
- `C:\HyperTwist` first-party product materials required for the assigned subsystem
|
||||
- `C:\Workspaces\HyperTwist\clean-room-specs\*`
|
||||
- `C:\Workspaces\HyperTwist\repos.manifest.json`
|
||||
- first-party acceptance tests and public compatibility requirements
|
||||
|
||||
## Forbidden for clean-room `Model B`
|
||||
|
||||
- `C:\Workspaces\HyperTwist\mirrors\restrictive\*`
|
||||
- mixed-license restricted subtrees inside otherwise partially permissive repos, for example:
|
||||
- `C:\Workspaces\HyperTwist\mirrors\restrictive\PostHog\posthog\ee\*`
|
||||
- `C:\Workspaces\HyperTwist\mirrors\restrictive\screenpipe\screenpipe\ee\*`
|
||||
- copied sensitive ops references such as:
|
||||
- `C:\HyperTwist\docs\refs\FORGEJO_WOODPECKER_VPS_A_TO_Z_SENSITIVE_RUNBOOK.md`
|
||||
- unrelated product ops folders, SSH material, or secret-bearing runbooks
|
||||
|
||||
## Operational rule
|
||||
|
||||
- if a file exists only because `Model A` inspected a restrictive repo, `Model B` must not read it unless it was explicitly scrubbed into `clean-room-specs`
|
||||
- benchmark oracles remain source-forbidden to `Model B`
|
||||
- this rule still applies when the upstream repo says `all rights reserved`, has no explicit license, or contains contradictory license notices; those repos may still inform `Model A`, but never become direct `Model B` source input
|
||||
- if a repo mixes permissive and restricted trees, default to forbidding the whole mirrored repo to `Model B` unless a narrower allowlist has been explicitly created in writing
|
||||
|
||||
## Brownan / Oracle clarification
|
||||
|
||||
Brownan's solver mirror is allowed for `Model A` research and oracle derivation only.
|
||||
It does not justify `Model B` access to any VPS runbook, CI document, SSH key, or other unrelated operations material.
|
||||
1745
docs/REPO_LICENSE_TRACKING.md
Normal file
1745
docs/REPO_LICENSE_TRACKING.md
Normal file
File diff suppressed because it is too large
Load diff
3763
docs/arch/CubeForge & CodeMatrix Initial Research.txt
Normal file
3763
docs/arch/CubeForge & CodeMatrix Initial Research.txt
Normal file
File diff suppressed because it is too large
Load diff
41
docs/arch/GPT-5.4 Pro Eval.txt
Normal file
41
docs/arch/GPT-5.4 Pro Eval.txt
Normal file
|
|
@ -0,0 +1,41 @@
|
|||
My neutral clinical opinion is that this is no longer just a repository-evaluation exercise. It has become a three-product portfolio architecture with a large candidate-universe operating system around it. That is both the strongest and the most dangerous aspect of the work. The strongest part is that the documentation now encodes a serious distinction between foundations, donors, sidecars, merge candidates, reserves, comparators, and exclusions. That prevents the common failure mode of treating every impressive repository as something to integrate directly. The dangerous part is that the corpus is now so large that a coding model, if given everything without discipline, will almost certainly overfit to whichever document or repo cluster it reads most recently. In other words, the documentation set is powerful, but it must be used as an indexed decision system, not as a giant prompt dump.
|
||||
|
||||
The project now has a recognizably mature internal logic. VectorShell is the large native spatial systems product; HyperTwist is the smaller but conceptually clean native puzzle and hypercube product; ScriptoriumAI is the already mostly built corpus-workspace and research-production product. This separation is important, because the three should not be developed with the same mental model. VectorShell is highest-upside and highest-complexity. HyperTwist is conceptually the cleanest. ScriptoriumAI is the nearest to product reality and should be treated as consolidation work rather than speculative greenfield ideation. If a model treats all three as equally unbuilt, it will produce bad plans. If it treats all three as already implemented, it will also produce bad plans. The documentation has now mostly corrected this, especially in v6.5, but the implementation workflow must keep repeating it.
|
||||
|
||||
The v6.3 portfolio board is a major achievement, but it should be understood clinically as a **candidate intelligence system**, not as an implementation-ready dependency graph. It contains 13,603 unique repo rows in the Phase G and operational boards. Of those, 9,236 are currently assigned to VectorShell, 971 to ScriptoriumAI, 156 to HyperTwist, 3,223 to multi-project, and 17 to future or adjacent use. Most rows are not “go build this now” rows: the largest bucket is Reserve Bench, followed by Comparator / Legacy, Donor Bench, and Exclude Current Horizon. Only a small number are locked foundations, locked parallel foundations, locked strategic donors, integrated product surfaces, or locked native foundations. This is exactly the right shape for a broad survey, because it means the corpus preserved options without pretending all options are equally urgent. However, it also means that anyone using the data must respect the buckets. The portfolio is not saying “integrate 13,603 things.” It is saying “here is the full design space, here are the current centers of gravity, and here is where source audit should focus first.”
|
||||
|
||||
The source-audit priority distribution reinforces that interpretation. The Phase G board has 56 P0 rows and 106 P1 rows; the overwhelming majority are P2 and P3. That is healthy. It means the portfolio contains a manageable practical front line hidden inside a very large research perimeter. The correct next move is not to re-review all 13,603 rows in free-form prose before coding. The correct next move is to use P0/P1 as the first source-audit and implementation decision surface, while keeping P2/P3 available for later re-evaluation. This is where the VS Code packets and source-audit board are crucial. They turn the enormous repo universe into actionable inspection tasks. Without that prioritization layer, the repository corpus would become a mental tax rather than an advantage.
|
||||
|
||||
VectorShell is the boldest and riskiest product, but also the one with the clearest differentiated upside if built according to the final architecture. The decisive correction was to make it Unreal-first rather than web-dashboard-first. That changes everything. If VectorShell becomes an Electron or browser graph viewer with 3D ornamentation, it will compete with many existing graph, IDE, dashboard, and observability tools and may not justify its complexity. If it becomes a native Unreal environment for code, systems, security, and binary artifacts, then it has a much stronger identity. The v6.5 manuals correctly define it as a spatial operating environment: codebase graphs, architecture maps, attack paths, reverse-engineering artifacts, and AI-mediated operations become objects in a navigable world. That is coherent. It is also a product that must be built in strict layers. The spatial foundation must work before the AI layer, security layer, and reverse-engineering layer attempt to dominate it.
|
||||
|
||||
The best clinical reading of VectorShell is that its first implementation target should be much narrower than its final design space. It should begin as an excellent native spatial graph navigator with importable architecture and repo data, not as a simultaneous VR IDE, pentest suite, reverse-engineering lab, AI coding agent, Kubernetes observability dashboard, and Kali appliance. All of those later layers are valid, and the documentation preserves them well, but the first shippable VectorShell must prove that its world model is useful with only the foundation layer enabled. The locked foundations, especially the graph and semantic-code candidates, give the right direction, but the engine must be made real in Unreal/C++ and not outsourced to generic web graph components. Rust sidecars for graph ingestion, security output normalization, and binary-analysis bridges are a strong architectural choice. C# should remain bounded and optional. Python and Node should not become the runtime spine.
|
||||
|
||||
The Kali and reverse-engineering layer is one of the best late additions to the portfolio, but it must remain properly bounded. The distinction between Kali package availability and upstream source architecture is now well understood. Kali package entries are enough to establish that a tool can be executed, wrapped, or made available in a Linux environment. Upstream repos are needed when source architecture, plugins, extension hooks, UI reuse, clean-room reimplementation, or deep integration are under review. That distinction should stay canonical. For VectorShell, most security tools should enter through subprocess, sidecar, parser, or normalized-output boundaries. Only a small number of primitive libraries or deeply valuable engines should be considered for native or near-native integration. The RE Stratum 1–4 model is clinically sound: analyst surfaces first, headless automation second, primitive native libraries third, and glue/companions fourth. It prevents the common error of trying to build a native Ghidra-like experience before even proving that the product can ingest and display binary-analysis findings usefully.
|
||||
|
||||
HyperTwist is the cleanest conceptually because it has fewer competing meanings. It is a dual-pillar product: physical cube recognition/coaching and higher-dimensional hypercube simulation/training. The v6.5 documentation correctly prevents the physical-cube side from swallowing the hypercube side, and vice versa. The likely nucleus remains a combination of higher-dimensional simulation, 3D twisty-puzzle logic, physical recognition, trainer logic, and replay/coaching systems. Clinically, HyperTwist should not begin as a massive generalized educational platform. It should begin by proving that its two pillars can talk to each other: a solve or puzzle state can be represented, replayed, explained, trained, and eventually made immersive. The Unreal-first posture is sensible because the product’s differentiator is spatial and embodied, not merely that it has another web trainer. But the first native implementation still needs a tight core loop. It must avoid the temptation to ingest every puzzle, every method, every event, every trainer, and every hyper-dimension before a user can feel the basic magic.
|
||||
|
||||
The most important HyperTwist risk is not technical sprawl at the same scale as VectorShell; it is dilution. There are many existing cube timers, trainers, solvers, visualization tools, and simulators. HyperTwist only becomes distinctive if it unifies the physical-to-virtual coaching pipeline with serious hypercube simulation. If it ships as just another trainer, it will not justify the architecture. If it ships as just a hypercube toy, it will remain niche. The product’s value lies in a bridge: recognition, replay, coaching, simulation, progression, and higher-dimensional understanding. The documentation now supports that bridge, but source audit must verify which repos truly provide reusable engines versus only superficial UI or old solver logic.
|
||||
|
||||
ScriptoriumAI is the project with the strongest current reality but also the most documentation drift. The uploaded architecture and API materials show a substantial implemented system: a React/Vite/TypeScript UI, Node/Express server, FastAPI visualizer, LaTeX OCR service, PostgreSQL/Redis-backed services, corpus APIs, compile orchestration, SyncTeX mapping, Smriti/reasoning-history APIs, collaboration APIs, artifact/run/entity/lineage systems, and a broad route surface. The screenshot and codebase snapshot evidence made clear that ScriptoriumAI is not just a planned product; it already has a large implemented body. The SAPI document also shows a deep server API surface around health, readiness, tasks, render proxying, corpus schema packs, structural queries, transactions, merge, reproducibility, novelty, replay, capabilities, policy, gates, observability, glyphs, entities, links, runs, artifacts, memory drift, Smriti, collaboration, SyncTeX, and compile enqueue. That is not a greenfield editor concept; it is a large application and platform that needs consolidation.
|
||||
|
||||
The most serious inconsistency in the current documentation set is ScriptoriumAI’s authority tension between the v6.3 row-level portfolio and the later v6.5 project manuals. The v6.3 Phase G board still contains older assumptions in which Outline and Excalidraw appear as locked foundations, and sharelatex/Overleaf-related rows still appear in the portfolio universe. The v6.5 manuals correctly override the active planning posture: ScriptoriumAI is Claude Prism–anchored, largely completed, and no longer Overleaf-centered. That correction is essential. However, it means that a coding model reading only the v6.3 CSVs can still be misled unless it also reads the v6.5 ScriptoriumAI manuals. Clinically, this is the clearest documentation-governance issue remaining. It does not invalidate the work, but it means the authority order must be enforced aggressively. For ScriptoriumAI, the project-specific v6.5 docs must outrank stale row-level assumptions when they conflict with the active project truth.
|
||||
|
||||
The ScriptoriumAI technology direction is also mostly sensible, but it should be applied with restraint. The desire to move the backbone toward Rust, C#, and C++ is coherent for performance, durability, and architectural clarity. Rust is especially fitting for corpus graph services, artifact processing, evidence pipelines, ingestion, indexing, and high-throughput API services. C# is plausible for bounded orchestration, approvals, retries, and enterprise-friendly control planes. C++ should be used only where there is a real native-processing justification. But ScriptoriumAI should not be rewritten destructively merely to satisfy the language preference. TypeScript remains appropriate for the UI. Python may remain appropriate for specialist OCR, visualization, or model-driven tasks. Node may remain temporarily appropriate where it already works and migration would risk destabilizing the product. The correct posture is strangler-pattern migration, not heroic rewrite.
|
||||
|
||||
The license strategy across the portfolio has matured considerably. The best part is that it no longer treats GPL/AGPL/strong copyleft as automatic rejection, nor does it treat reverse engineering as a universal default. The four-mode strategy—incorporate as-is, bounded sidecar, reverse engineer, pattern-only—is the correct clinical framework. For VectorShell, this is especially important because security and RE tools often make sense as sidecars or subprocess-driven tools. For ScriptoriumAI, this is important because future repo additions must be evaluated against a mostly completed product and cannot casually drag in obligations that complicate an already functioning platform. For HyperTwist, the strategy matters because some simulation engines may be worth direct use, while others are better as pattern or algorithm donors. The remaining weakness is factual license completeness: the documents themselves acknowledge that the RE layer did not receive a final narrow license verification pass. That should be done before any direct incorporation decision, especially for RE suites, GUI frameworks, and deeply embedded libraries.
|
||||
|
||||
The documentation system is now large enough that it needs disciplined consumption. The v6.3 CSVs are machine-readable and decision-heavy. The narrative bundles are prose-heavy and helpful for context. The v6.5 manuals are project-specific and implementation-oriented. Those layers should not be collapsed into one giant model context unless the goal is broad summarization. A coding model working on a repo audit should receive the relevant repo row, the project manual, the local narrative paragraph, and the actual source tree. It should not receive every narrative volume every time. Conversely, a model asked to produce an architecture roadmap should receive the project manuals, the relevant Volume 0 and main project volume, and the Phase G/source-audit boards. The documentation is strong, but its volume makes context hygiene essential.
|
||||
|
||||
The narrative companion volumes are valuable but should be treated as interpretive prose rather than final implementation truth. They are excellent for helping humans and models understand why a repo exists in the portfolio and how it might transfer across projects. They are less reliable than source inspection for deciding whether a repo’s internal code is actually reusable. This is not a flaw; it is the nature of pre-source-audit work. The VectorShell narrative volume is especially large, reflecting the breadth of the platform/security/RE/tooling universe. HyperTwist’s narrative bundle is smaller and more focused, which is a strength. ScriptoriumAI’s narrative bundle is useful but must be read through the v6.5 override because some row-level classifications still reflect earlier candidate thinking rather than the final Claude Prism–anchored reality.
|
||||
|
||||
From a portfolio perspective, the three projects form a coherent intellectual family but not a single product. Their shared theme is structured work made navigable: VectorShell makes code and systems navigable, HyperTwist makes puzzle states and higher-dimensional structures navigable, and ScriptoriumAI makes corpora, documents, research, diagrams, and artifacts navigable. That commonality is real and useful. But the products must remain operationally separate. The danger is cross-bleeding: Unreal and VR concepts do not belong in ScriptoriumAI’s core; ScriptoriumAI’s document/corpus architecture should not become the default backend for HyperTwist; HyperTwist’s puzzle logic should not be forced into VectorShell except as a conceptual or rendering donor where it truly helps. The v6.5 manuals have mostly corrected this by splitting AGENTS, SKILLS, ARCHITECTURE, API, DEVELOPMENT, PRD, LICENSETRACKING, and ROADMAP per project.
|
||||
|
||||
The distribution strategy that emerges from the documents is also clinically sound. ScriptoriumAI fits a web plus Tauri-style desktop model because it is UI/workspace/document heavy and can keep a Rust-backed or Rust-adjacent service core behind a webview shell. VectorShell and HyperTwist should not be Tauri-first. They are Unreal-native products and should be distributed as native Unreal builds. VectorShell may additionally need an optional Linux-enhanced appliance/VM mode for hardware-dependent or Linux-specific security workflows, but that should not be required for the normal desktop experience. This is a clean separation: normal cross-platform mode for most users, Linux-enhanced mode for advanced security capabilities, and no attempt to pretend Kali kernel features are portable to Windows and macOS.
|
||||
|
||||
The most important practical next step is not more document generation. It is source-grounded validation. The documents are now good enough to guide work, but they cannot prove source-level reuse value. The correct workflow is to start VS Code source audits using the v6.3 source-audit board and VS Code packets, beginning with P0/P1 repos in one project at a time. ScriptoriumAI should go first because it is already implemented and has the clearest consolidation path. The task there is to map current-state to target-state, identify latest repo integrations, and decide which services should eventually move to Rust/C#/C++ without destabilizing the product. VectorShell should follow because its architecture is broad and needs a careful Unreal-native skeleton before repo sprawl begins. HyperTwist should follow because it is conceptually clear but still needs source validation of the simulation, recognition, trainer, and replay foundations.
|
||||
|
||||
My clinical assessment of viability is this: ScriptoriumAI is closest to an actual product and should be treated as an engineering consolidation program; VectorShell is the most ambitious and differentiated but needs ruthless phase discipline; HyperTwist is the cleanest product concept but depends on executing a strong nucleus rather than becoming a bag of cube tools. The overall portfolio is internally coherent, but only if the documentation’s separation rules are obeyed. If every repo is treated as equal and every project is treated as equally unbuilt, the portfolio will become unmanageable. If the P0/P1 audit discipline is respected, the project has a credible path.
|
||||
|
||||
My clinical assessment of the documentation itself is that it is unusually rich, but uneven. The strongest components are the Phase G board, operational board, source-audit board, VS Code packets, copyleft strategy matrix, RE matrix, and v6.5 project manuals. The weakest component is the residue of older ScriptoriumAI assumptions in some row-level artifacts. The narrative bundles are useful but voluminous and should not be treated as the first thing a coding model reads. The licensing matrix is strategically mature but not legally complete. The RE layer is architecturally well-framed but requires source audit and license verification before direct incorporation decisions. The project manuals are now much better separated, though they could still be expanded into book-length manuals if desired. I would not expand them further before beginning source audits, because additional prose will now have diminishing returns compared with source-grounded evidence.
|
||||
|
||||
The final neutral judgment is that the project is no longer primarily lacking ideas, candidate repos, or architecture language. It is now lacking execution evidence. The documentation has reached the point where more conceptual expansion is less valuable than starting the first serious implementation and source-audit loop. The healthiest next phase is therefore not another global brainstorming pass. It is a disciplined engineering loop: choose one project, load the focused docs, inspect the source repos, produce evidence-backed deltas, update the board, and only then implement. If you do that, the documentation becomes a powerful operating system for development. If you instead hand the entire corpus to models and ask them to “decide,” they will recreate confusion the documents were designed to prevent.
|
||||
7168
docs/arch/Grok Repos Evaluation Salvaged.txt
Normal file
7168
docs/arch/Grok Repos Evaluation Salvaged.txt
Normal file
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,19 @@
|
|||
1. Extract Key files and architecture from Scriptorium code base. Agents MD, Docker Ignore MD, Legal MD Extract AGPL architecture from scriptorium and reuse. In case of AGPL GPL and strong copy left repos
|
||||
|
||||
2. Make extracted files project agnostic only retaining high value neutral information
|
||||
|
||||
3. Provide models with initialization context. for both projects
|
||||
|
||||
4. First Present with open source repos a gpl gpl inclusion will be unavoidable settle upon the correct approach architecture and cleanly Track and record licensing needs for each repo utilized discuss with each model, inquire upon and settle on the correct architecture.
|
||||
|
||||
Do an entire pass with each model just on the legal file to make sure we are legally in the clear cans and cannots are clear, everybody is on the same page and architecture is clear.
|
||||
|
||||
!!Insert it into the provided Default and extracted Scriptorium amalgamated (salvaged folder) architecture file structure.!! Establish initial documentation with legal file and architecture
|
||||
|
||||
5. Then in another parse request the models to re-evaluate established architecture and how it could be refined by enhancement and or omission.
|
||||
|
||||
6. Next round ask each model to enhance initial context with further ideas and comprehensive feature sets if sensible, sensical and applicable.
|
||||
|
||||
7. Next round inquire each model again if the added ideas and feature sets are sensible sensical and realistic for the project shave off or add to as needed
|
||||
|
||||
8. Convert product requirement document into a final roadmap implementation schedule
|
||||
748
docs/arch/HyperTwist Curated Repository Candidate Ledger.txt
Normal file
748
docs/arch/HyperTwist Curated Repository Candidate Ledger.txt
Normal file
File diff suppressed because one or more lines are too long
BIN
docs/arch/HyperTwist Raw Repository Ledger 2026-04-09.zip
Normal file
BIN
docs/arch/HyperTwist Raw Repository Ledger 2026-04-09.zip
Normal file
Binary file not shown.
2101
docs/arch/HyperTwist Raw Repository Ledger.txt
Normal file
2101
docs/arch/HyperTwist Raw Repository Ledger.txt
Normal file
File diff suppressed because it is too large
Load diff
104
docs/arch/HyperTwist Repository Catalog and Licenses.txt
Normal file
104
docs/arch/HyperTwist Repository Catalog and Licenses.txt
Normal file
|
|
@ -0,0 +1,104 @@
|
|||
HyperTwist Repository Catalog and Licenses
|
||||
Date: 2026-04-09
|
||||
Status: Fourth-pass consolidation. HyperTwist-only. Reconciled against the curated candidate ledger, with shared-file VectorShell spillover still intentionally excluded from this tagged catalog.
|
||||
|
||||
Parsed end to end for this pass
|
||||
- C:\HyperTwist\CubeForge & CodeMatrix Initial Research.txt
|
||||
- C:\HyperTwist\HyperTwist Design Language.txt
|
||||
- C:\HyperTwist\HyperTwist Marketing Pitch.txt
|
||||
- C:\HyperTwist\HyperTwist ScriptoriumAI Reuse Findings.txt
|
||||
|
||||
Supporting verification used in this pass
|
||||
- C:\HyperTwist\HyperTwist Curated Repository Candidate Ledger.txt
|
||||
- C:\ScriptoriumAI\tmp\mirror_remotes.txt
|
||||
- local LICENSE files under C:\ScriptoriumAI\mirrors\...
|
||||
- current GitHub license metadata checked on 2026-04-08 for the repos that were missing or inconsistent in the earlier draft
|
||||
|
||||
How to read this file
|
||||
- Direct candidate = normal commercial reuse looks license-compatible, subject to ordinary attribution/notice duties.
|
||||
- Direct candidate with care = technically usable, but the license or packaging needs extra design/legal discipline before adoption.
|
||||
- Reference only = useful for ideas, subprocess boundaries, benchmarks, or feature study; do not transplant directly into a proprietary core.
|
||||
- Blocked until clarified = no dependable open-source license signal in this pass, or the repo is otherwise unsuitable for direct proprietary reuse.
|
||||
|
||||
1. Core cube vision, AR, and solve-reconstruction options
|
||||
- kkoomen/qbr | https://github.com/kkoomen/qbr | MIT License | Direct candidate | Highest-priority webcam/OpenCV starter for live cube-state recognition.
|
||||
- vivaansinghvi07/rubix-cube-solver | https://github.com/vivaansinghvi07/rubix-cube-solver | MIT License | Direct candidate | Strong post-solve reconstruction and replay option.
|
||||
- cahidenes/rubiks-cube-solver | https://github.com/cahidenes/rubiks-cube-solver | MIT License | Direct candidate | Good OpenCV plus Kociemba path for fast state-to-solution features.
|
||||
- tentone/rubix-solver | https://github.com/tentone/rubix-solver | MIT License stated in the current public README on 2026-04-09; GitHub license API was inconsistent in the earlier pass | Direct candidate | Public repo still exists and remains a viable OpenCV baseline.
|
||||
- yakupbilen/drl-rubiks-cube | https://github.com/yakupbilen/drl-rubiks-cube | MIT License | Reference only | Interesting RL-plus-webcam reference, but not a first-line production starter.
|
||||
|
||||
2. Core training, drilling, timer, and blindfolded-solving options
|
||||
- poliva/cubedex | https://github.com/poliva/cubedex | MIT License | Direct candidate | Strong lightweight alg-drilling base.
|
||||
- tao-yu/Alg-Trainer | https://github.com/tao-yu/Alg-Trainer | MIT License | Direct candidate | Broadest mature algorithm-set trainer in the HyperTwist source corpus.
|
||||
- Lykos/cube_trainer | https://github.com/Lykos/cube_trainer | MIT License | Direct candidate | Smart-sampled training and BLD overlap.
|
||||
- abunickabhi/5style-Trainer | https://github.com/abunickabhi/5style-Trainer | MIT License | Direct candidate | Distinct BLD/5-style option explicitly named in the HyperTwist research.
|
||||
- newyork-anthonyng/rubiks-cross-trainer | https://github.com/newyork-anthonyng/rubiks-cross-trainer | MIT License | Direct candidate | Useful focused cross-training option that was missing from the earlier catalog.
|
||||
- Aarav2709/KubeTimr | https://github.com/Aarav2709/KubeTimr | MIT License | Direct candidate | Lightweight offline timer option from the HyperTwist research pass.
|
||||
- onionhoney/roux-trainers | https://github.com/onionhoney/roux-trainers | GNU General Public License v3.0 | Reference only | Method-specific trainer worth studying, not a direct proprietary code donor.
|
||||
- kash/cubedesk | https://github.com/kash/cubedesk | GNU General Public License v3.0 | Reference only | Best-in-class full-platform benchmark for analytics and training breadth.
|
||||
- cs0x7f/cstimer | https://github.com/cs0x7f/cstimer | GNU General Public License v3.0 | Reference only | Gold-standard timer benchmark, not a closed-core donor.
|
||||
- AviKaufman/Rubix-cube-trainer | https://github.com/AviKaufman/Rubix-cube-trainer | Current GitHub license metadata did not expose a license file in this pass | Blocked until clarified | Keep as concept/reference only.
|
||||
- ambisinister/blindsolve | https://github.com/ambisinister/blindsolve | Current GitHub license metadata did not expose a license file in this pass | Blocked until clarified | Keep as concept/reference only.
|
||||
- alinen/cube | https://github.com/alinen/cube | Current GitHub license metadata did not expose a license file in this pass | Blocked until clarified | Keep as concept/reference only.
|
||||
|
||||
3. Hypercubing, dimensional simulation, and reusable foundations
|
||||
- HactarCE/Hyperspeedcube | https://github.com/HactarCE/Hyperspeedcube | Dual licensed: MIT License OR Apache License 2.0 | Direct candidate | The clearest hypercubing engine candidate and the strongest 3D-7D bridge in the source set.
|
||||
- cubing/cubing.js | https://github.com/cubing/cubing.js | GitHub license metadata currently reports GNU General Public License v3.0; the attached research earlier described MPL-2.0 plus mixed vendored parts | Direct candidate with care | Treat as a boundary-sensitive foundation until the exact packaging/reuse plan is license-cleared.
|
||||
|
||||
4. Additional solver and simulator benchmarks explicitly named in the HyperTwist research
|
||||
- efrantar/rob-twophase | https://github.com/efrantar/rob-twophase | GNU General Public License v3.0 | Reference only | High-speed solver benchmark.
|
||||
- vwcwong/CubeSim | https://github.com/vwcwong/CubeSim | GNU General Public License v3.0 | Reference only | Simulator/solver benchmark.
|
||||
- nealmick/Cube | https://github.com/nealmick/Cube | GNU General Public License v3.0 | Reference only | Visualizer/solver benchmark.
|
||||
- brownan/Rubiks-Cube-Solver | https://github.com/brownan/Rubiks-Cube-Solver | GNU General Public License v3.0 | Reference only | Pattern-database solver benchmark.
|
||||
- MathewKJ2048/Rubiks-cube-simulator | https://github.com/MathewKJ2048/Rubiks-cube-simulator | GNU General Public License v3.0 | Reference only | Java simulator/solver benchmark.
|
||||
- ShellPuppy/RCube | https://github.com/ShellPuppy/RCube | GNU General Public License v3.0 | Reference only | Large-cube solver benchmark.
|
||||
|
||||
5. Speech, narration, and local coaching sidecars
|
||||
- ggml-org/whisper.cpp | https://github.com/ggml-org/whisper.cpp | MIT License | Direct candidate | Native C++ STT option. The attached source text used the older `ggerganov/whisper.cpp` naming.
|
||||
- SYSTRAN/faster-whisper | https://github.com/SYSTRAN/faster-whisper | MIT License | Direct candidate | Strong Python/subprocess STT lane.
|
||||
- rhasspy/piper | https://github.com/rhasspy/piper | MIT License | Direct candidate | Best local TTS candidate from the HyperTwist corpus.
|
||||
|
||||
6. Optional HyperTwist support repos pulled in through ScriptoriumAI-linked materials
|
||||
- code2video | https://git.scriptoriumai.io/scriptoriumadmin/code2video.git | MIT License | Direct candidate | Optional coaching/export lane for generated explainer clips; not a gameplay/runtime dependency.
|
||||
- paper2video | https://git.scriptoriumai.io/scriptoriumadmin/paper2video.git | MIT License | Reference only | Optional sibling media-generation lane.
|
||||
- remotion | https://git.scriptoriumai.io/scriptoriumadmin/remotion.git | Remotion License | Direct candidate with care | Useful for export/render pipelines, but the license is not standard permissive OSS.
|
||||
- supermemory | https://github.com/supermemoryai/supermemory.git | MIT License | Reference only | Long-term coaching memory and provenance reference.
|
||||
- ReMe | https://github.com/agentscope-ai/ReMe.git | Apache License 2.0 | Reference only | Memory/reasoning reference.
|
||||
- mind-map | https://git.scriptoriumai.io/scriptoriumadmin/mindmap.git | MIT License | Reference only | Optional diagram/planning surface, not a HyperTwist runtime dependency.
|
||||
- next-ai-draw-io | https://git.scriptoriumai.io/scriptoriumadmin/nextaidrawio.git | Apache License 2.0 | Reference only | Optional AI-diagramming reference.
|
||||
- skillhub | https://github.com/iflytek/skillhub.git | Apache License 2.0 | Reference only | Development/workflow reference, not customer-facing runtime.
|
||||
- OpenSpace | https://github.com/HKUDS/OpenSpace.git | MIT License | Reference only | Workflow/reference surface.
|
||||
- Roo-Code | https://github.com/RooVetGit/Roo-Code.git | Apache License 2.0 | Reference only | Editor/agent workflow reference.
|
||||
- veritas-kanban | https://git.scriptoriumai.io/scriptoriumadmin/veritas-kanban.git | MIT License | Reference only | Development and maintenance workflow reference.
|
||||
|
||||
7. Fourth-pass consolidation note
|
||||
- Removed from this file as VectorShell-only spillover: Kali Linux, BloodHound, Strix, xalgorix, Forge, Forgecode, Docker/Kubernetes/AWS/Azure/Grafana/Kong infra repos, Monaco Editor, VS Code, and the rest of the VectorShell security/infra layer.
|
||||
- Kept as shared cross-project items only where the HyperTwist materials themselves explicitly called for them: Hyperspeedcube, whisper.cpp, faster-whisper, and piper.
|
||||
- Final reconciliation used C:\HyperTwist\HyperTwist Curated Repository Candidate Ledger.txt. The remaining validated extras in the shared research file were either VectorShell-side spillover or intentionally left in the ledgers rather than promoted into this HyperTwist-only catalog.
|
||||
|
||||
8. Practical shortlist from this corrected HyperTwist pass
|
||||
- Strongest direct nucleus: qbr + vivaansinghvi07/rubix-cube-solver + cubedex + Alg-Trainer + cube_trainer + Hyperspeedcube + whisper.cpp or faster-whisper + piper.
|
||||
- Strongest lower-risk additions that were missing before: rubiks-cross-trainer + KubeTimr + 5style-Trainer.
|
||||
- Main legal tripwires: cubing.js is currently license-ambiguous versus the earlier research notes, and several smaller trainers still do not expose a dependable license signal in the current upstream metadata.
|
||||
|
||||
9. Final-pass verification notes
|
||||
- One real correction from the final pass: `tentone/rubix-solver` is still live and its current public README still states MIT, so it moved back into the direct-candidate pool.
|
||||
- `ggerganov/whisper.cpp` in the source corpus continues to resolve to the current canonical upstream `ggml-org/whisper.cpp`.
|
||||
- `AviKaufman/Rubix-cube-trainer`, `ambisinister/blindsolve`, and `alinen/cube` still did not yield a dependable current license signal in this pass, so they remain blocked rather than guessed.
|
||||
- No additional HyperTwist-only repos were promoted during the final ledger reconciliation; the remaining high-signal validated additions belonged to the VectorShell branch of the shared research corpus.
|
||||
|
||||
10. Requested follow-up additions from ScriptoriumAI and NyxOS
|
||||
- FeatureBaseDB/featurebase | Public upstream: https://github.com/FeatureBaseDB/featurebase ; Scriptorium local mirror: C:\ScriptoriumAI\mirrors\featurebase | Apache License 2.0 | Direct candidate with care | Public changelog/feedback/support surface only. The community repo in this snapshot is archived, so do not make it foundational.
|
||||
- supertokens/supertokens-auth-react | Public upstream: https://github.com/supertokens/supertokens-auth-react ; Scriptorium local mirror: C:\ScriptoriumAI\mirrors\supertokens-auth-react | Apache License 2.0 | Direct candidate | Auth/account surface option. Scriptorium uses branded wrappers instead of stock pages.
|
||||
- itshover/itshover | Public upstream: https://github.com/itshover/itshover ; Scriptorium local mirror: C:\ScriptoriumAI\mirrors\itshover | Local mirror LICENSE file is Apache License 2.0, while the current README still says MIT | Direct candidate with care | Motion/icon system for marketing, support, account, or companion-app surfaces. Verify upstream license signal before vendoring.
|
||||
- woltapp/blurhash | https://github.com/woltapp/blurhash ; NyxOS local mirror: C:\NyxOS\mirror_repositories\blurhash | MIT License | Direct candidate | Lightweight placeholders for launchers, replay cards, exports, galleries, and support surfaces.
|
||||
- met4citizen/TalkingHead | https://github.com/met4citizen/TalkingHead ; NyxOS local mirror: C:\NyxOS\mirror_repositories\talkinghead | MIT License | Direct candidate with care | Coaching avatar / narrated tutorial companion option.
|
||||
- mediar-ai/screenpipe | https://github.com/mediar-ai/screenpipe ; NyxOS local mirror: C:\NyxOS\mirror_repositories\screenpipe | MIT License | Direct candidate with care | Session capture, searchable training history, and replay indexing for coaching/support tooling.
|
||||
- prompt-compressor | NyxOS local mirror only in the current snapshot: C:\NyxOS\mirror_repositories\prompt-compressor | MIT License | Direct candidate for internal tooling only | Good prompt/document compression helper, but the public upstream URL was not preserved in the local snapshot.
|
||||
- apache/echarts | https://github.com/apache/echarts ; NyxOS local mirror: C:\NyxOS\mirror_repositories\echarts | Apache License 2.0 | Direct candidate | Analytics, telemetry, and reporting dashboard layer.
|
||||
- bytebot-ai/bytebot | https://github.com/bytebot-ai/bytebot ; NyxOS local mirror: C:\NyxOS\bytebot | Apache License 2.0 | Direct candidate with care | Useful for QA, support automation, content pipeline tasks, and operator workflows.
|
||||
- bytedance/UI-TARS-desktop | https://github.com/bytedance/UI-TARS-desktop ; NyxOS local mirror: C:\NyxOS\mirror_repositories\ui-tars-desktop | Apache License 2.0 | Direct candidate with care | Agent-based testing, browser/desktop operators, and internal tooling.
|
||||
- rdev/liquid-glass-react | https://github.com/rdev/liquid-glass-react ; NyxOS local mirror: C:\NyxOS\mirror_repositories\liquidglassreact | MIT License | Reference only unless HyperTwist explicitly wants this exact companion-app visual direction | Pure UI polish.
|
||||
- Writerside is intentionally kept in the ScriptoriumAI reuse findings rather than this repo matrix because the active asset is the project-local `C:\ScriptoriumAI\Writerside` docs tree, not a mirrored repo row.
|
||||
|
||||
This file is a repository-options matrix only. It does not approve vendoring, relicensing, or direct code transplantation by itself.
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
# HyperTwist — Volume 0
|
||||
|
||||
## Canonical Preface
|
||||
|
||||
This bundle is the HyperTwist narrative companion generated from the v6.3 portfolio truth and the v6.5 deep project manuals.
|
||||
|
||||
### Authority order
|
||||
1. `repo_portfolio_unified_v6_3.*` and companion matrices
|
||||
2. `v6_5_deep_manual_pack/HyperTwist/*`
|
||||
3. earlier broad portfolio documents as lineage only
|
||||
|
||||
### Scope of this bundle
|
||||
- **Volume 2** contains HyperTwist-first repo narratives.
|
||||
- **Volume 4** contains cross-project, reserve, comparator, and adjacent repos that are not primarily assigned to HyperTwist but are explicitly flagged as transfer-relevant to it.
|
||||
|
||||
### Collapse rules applied
|
||||
- exact duplicate repo entries collapsed
|
||||
- same repo bookmarked under multiple GitHub tabs collapsed
|
||||
- obvious upstream/mirror duplicates collapsed where they point to the same source target
|
||||
- non-repo topic/index/search pages omitted
|
||||
- plain non-source web links omitted
|
||||
|
||||
### HyperTwist posture
|
||||
HyperTwist remains a dual-pillar product:
|
||||
- a practical physical-cube recognition, replay, and coaching platform
|
||||
- a serious higher-dimensional hypercube simulation and training environment
|
||||
|
||||
The active architecture bias is:
|
||||
- Unreal Engine 5.4+
|
||||
- C++ and Blueprints at the runtime center
|
||||
- Rust or C++ for algorithmic and performance-sensitive puzzle logic
|
||||
- bounded C# only where orchestration or durable background services truly benefit
|
||||
- minimal TypeScript / Node.js / Python outside genuinely justified subsystems
|
||||
|
||||
### Bundle counts
|
||||
- Volume 2 narratives: 156
|
||||
- Volume 4 narratives: 4143
|
||||
|
|
@ -0,0 +1,335 @@
|
|||
# HyperTwist — Volume 2
|
||||
|
||||
|
||||
## Locked Foundation
|
||||
|
||||
**HactarCE/Hyperspeedcube** is a HyperTwist-first portfolio candidate in **Locked Foundation**, currently treated as **locked core candidate** with primary archetype **foundation engine**. It is relevant because it contributes HactarCE/Hyperspeedcube — MIT OR Apache-2.0 — Modern 3D/4D puzzle simulator (thousands of puzzles). | This makes CubeForge the first true hypercubing training platform — solving every pain point while keeping the 3D core rock-solid.Exten... to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a hypercubing / nD simulation subsystem for HyperTwist. Preserve the strongest existing pieces — nD state model, move notation, renderer, projection controls, solver/traversal logic, puzzle serialization, replay — and expose them behind a portfolio-stable interface. Wire first into cubing/cubing.js, then into tao-yu/Alg-Trainer for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a higher-dimensional renderer/simulator donor and shared interaction grammar for HyperTwist and long-horizon VectorShell. Source inspection should focus on Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.. The strongest currently noted combinations are cubing/cubing.js, tao-yu/Alg-Trainer, cross-project transfer candidate. Primary URL: https://github.com/HactarCE/Hyperspeedcube
|
||||
|
||||
**kkoomen/qbr** is a HyperTwist-first portfolio candidate in **Locked Foundation**, currently treated as **locked core candidate** with primary archetype **foundation engine**. It is relevant because it contributes kkoomen/qbr — MIT — Webcam-based 3x3 solver with accurate OpenCV color detection (perfect vision starter). | kkoomen/qbr — MIT — Webcam CV solver (base for 3D vision). | kkoomen/qbr — MIT — Webcam CV color detection. | poliva/cubedex, ta... to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a computer vision / AR subsystem for HyperTwist. Preserve the strongest existing pieces — camera ingest, calibration, segmentation/detection, pose or facelet extraction, state normalization, solver bridge, replay overlay, AR anchors — and expose them behind a portfolio-stable interface. Wire first into vivaansinghvi07/rubix-cube-solver, then into cubing/cubing.js for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a perception microservice, cube-state API, replay generator, or AR overlay donor for HyperTwist. Source inspection should focus on Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.. The strongest currently noted combinations are vivaansinghvi07/rubix-cube-solver, cubing/cubing.js, cross-project transfer candidate. Primary URL: https://github.com/kkoomen/qbr
|
||||
|
||||
**cubing/cubing.js** is a HyperTwist-first portfolio candidate in **Locked Foundation**, currently treated as **locked core candidate** with primary archetype **foundation engine**. It is relevant because it contributes Other Notable ResourcesCubing.js library (for building your own tools): https://github.com/cubing/cubing.js – Open-source core used in many trainers above. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a ui / design / frontend subsystem for HyperTwist. Preserve the strongest existing pieces — component library, canvas/animation engine, interaction patterns, layout/state models, accessibility hooks, theming, editor widgets — and expose them behind a portfolio-stable interface. Wire first into HactarCE/Hyperspeedcube, then into kkoomen/qbr for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a frontend interaction donor, canvas/editor pattern library, or polished shell layer on top of existing anchors. Source inspection should focus on Inspect scene graph/canvas data model; layout primitives; component library; keyboard/gesture interactions; import/export schema; theming; plugin or extension hooks.. The strongest currently noted combinations are project-local anchor, shared portfolio utility, cross-project transfer candidate. Primary URL: https://github.com/cubing/cubing.js
|
||||
|
||||
|
||||
## Locked Parallel Foundation
|
||||
|
||||
**vivaansinghvi07/rubix-cube-solver** is a HyperTwist-first portfolio candidate in **Locked Parallel Foundation**, currently treated as **locked core candidate** with primary archetype **foundation engine**. It is relevant because it contributes Yes — 100% possible to consolidate everything into one no-compromises, enterprise-grade platform. You're not half-arsing it, and neither am I. Modern vision models (and even classical OpenCV pipelines refined over the last decade) are mo... to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a computer vision / AR subsystem for HyperTwist. Preserve the strongest existing pieces — camera ingest, calibration, segmentation/detection, pose or facelet extraction, state normalization, solver bridge, replay overlay, AR anchors — and expose them behind a portfolio-stable interface. Wire first into kkoomen/qbr, then into cubing/cubing.js for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a perception microservice, cube-state API, replay generator, or AR overlay donor for HyperTwist. Source inspection should focus on Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.. The strongest currently noted combinations are kkoomen/qbr, cubing/cubing.js, cross-project transfer candidate. Primary URL: https://github.com/vivaansinghvi07/rubix-cube-solver
|
||||
|
||||
**tao-yu/Alg-Trainer** is a HyperTwist-first portfolio candidate in **Locked Parallel Foundation**, currently treated as **locked core candidate** with primary archetype **foundation engine**. It is relevant because it contributes Alg-Trainer (tao-yu/Alg-Trainer) | tao-yu/Alg-Trainer — MIT — Most powerful multi-set alg trainer (ZBLL, full custom sets, smartcube/virtual cube). Live: https://tao-yu.github.io/Alg-Trainer/. | tao-yu/Alg-Trainer — MIT — Multi-set alg t... to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into poliva/cubedex, then into Lykos/cube_trainer for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.. The strongest currently noted combinations are poliva/cubedex, Lykos/cube_trainer, cross-project transfer candidate. Primary URL: https://github.com/tao-yu/Alg-Trainer
|
||||
|
||||
|
||||
## Locked Strategic Donor
|
||||
|
||||
**cahidenes/rubiks-cube-solver** is a HyperTwist-first portfolio candidate in **Locked Strategic Donor**, currently treated as **candidate core** with primary archetype **foundation engine**. It is relevant because it contributes cahidenes/rubiks-cube-solver — MIT — OpenCV cube detection + Kociemba solver. | cahidenes/rubiks-cube-solver — MIT — OpenCV + solver. | Yes — we already have several strong open-source visual models for cube recognition from earlier in o... to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a computer vision / AR subsystem for HyperTwist. Preserve the strongest existing pieces — camera ingest, calibration, segmentation/detection, pose or facelet extraction, state normalization, solver bridge, replay overlay, AR anchors — and expose them behind a portfolio-stable interface. Wire first into kkoomen/qbr, then into vivaansinghvi07/rubix-cube-solver for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a perception microservice, cube-state API, replay generator, or AR overlay donor for HyperTwist. Source inspection should focus on Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.. The strongest currently noted combinations are kkoomen/qbr, vivaansinghvi07/rubix-cube-solver, cubing/cubing.js. Primary URL: https://github.com/cahidenes/rubiks-cube-solver
|
||||
|
||||
**tentone/rubix-solver** is a HyperTwist-first portfolio candidate in **Locked Strategic Donor**, currently treated as **candidate core** with primary archetype **foundation engine**. It is relevant because it contributes tentone/rubix-solver — MIT — OpenCV cube detection. | Yes — 100% possible to consolidate everything into one no-compromises, enterprise-grade platform. You're not half-arsing it, and neither am I. Modern vision models (and even classical... to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a computer vision / AR subsystem for HyperTwist. Preserve the strongest existing pieces — camera ingest, calibration, segmentation/detection, pose or facelet extraction, state normalization, solver bridge, replay overlay, AR anchors — and expose them behind a portfolio-stable interface. Wire first into kkoomen/qbr, then into vivaansinghvi07/rubix-cube-solver for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a perception microservice, cube-state API, replay generator, or AR overlay donor for HyperTwist. Source inspection should focus on Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.. The strongest currently noted combinations are kkoomen/qbr, vivaansinghvi07/rubix-cube-solver, cubing/cubing.js. Primary URL: https://github.com/tentone/rubix-solver
|
||||
|
||||
**Lykos/cube_trainer** is a HyperTwist-first portfolio candidate in **Locked Strategic Donor**, currently treated as **candidate core** with primary archetype **foundation engine**. It is relevant because it contributes Lykos/cube_trainer — MIT — Smart-sampled training. | CubeTrainer (Lykos/cube_trainer) | Lykos/cube_trainer — MIT — Smart-sampled alg/BLD trainer. Live: https://www.cubetrainer.org. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.. The strongest currently noted combinations are tao-yu/Alg-Trainer, poliva/cubedex, cross-project transfer candidate. Primary URL: https://github.com/Lykos/cube_trainer
|
||||
|
||||
**kash/cubedesk** is a HyperTwist-first portfolio candidate in **Locked Strategic Donor**, currently treated as **candidate core** with primary archetype **foundation engine**. It is relevant because it contributes AGPL / GPL / Strong Copyleft (Forces open-sourcing derivatives — study/reference only or use as backend/service; avoid for closed-source core)kash/cubedesk — GPL-3.0 — Full timer + 750+ alg trainers + analytics/community platform. Live: ... to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a hypercubing / nD simulation subsystem for HyperTwist. Preserve the strongest existing pieces — nD state model, move notation, renderer, projection controls, solver/traversal logic, puzzle serialization, replay — and expose them behind a portfolio-stable interface. Wire first into HactarCE/Hyperspeedcube, then into cubing/cubing.js for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a higher-dimensional renderer/simulator donor and shared interaction grammar for HyperTwist and long-horizon VectorShell. Source inspection should focus on Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, tao-yu/Alg-Trainer. Primary URL: https://github.com/kash/cubedesk
|
||||
|
||||
**poliva/cubedex** is a HyperTwist-first portfolio candidate in **Locked Strategic Donor**, currently treated as **candidate core** with primary archetype **foundation engine**. It is relevant because it contributes poliva/cubedex — MIT — Smartcube alg trainer. | Open source repositories and software specifically designed to drill ("hammer") Rubik's Cube algorithms into muscle memory through repeated practice, timing, smart sampling, real scrambles,... to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into Lykos/cube_trainer for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect scene graph/canvas data model; layout primitives; component library; keyboard/gesture interactions; import/export schema; theming; plugin or extension hooks.. The strongest currently noted combinations are project-local anchor, shared portfolio utility, cross-project transfer candidate. Primary URL: https://github.com/poliva/cubedex
|
||||
|
||||
**cs0x7f/cstimer** is a HyperTwist-first portfolio candidate in **Locked Strategic Donor**, currently treated as **candidate core** with primary archetype **foundation engine**. It is relevant because it contributes Other open-source tools worth noting (more general solvers/simulators but useful for learning/practicing alg execution): csTimer (cs0x7f/cstimer) – https://github.com/cs0x7f/cstimer | Live: https://cstimer.net – Professional open-source ... to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.. The strongest currently noted combinations are tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer. Primary URL: https://github.com/cs0x7f/cstimer
|
||||
|
||||
|
||||
## Donor Bench
|
||||
|
||||
**Hypercubers/hypercubing.xyz** is a HyperTwist-first portfolio candidate in **Donor Bench**, currently treated as **donor bench** with primary archetype **subsystem donor**. It is relevant because it contributes Website for the Hypercubing community to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Repurpose selected subsystems rather than the whole product. Mine the repo for nD state model, move notation, renderer, projection controls, solver/traversal logic, puzzle serialization, replay; keep what materially shortens build time, but rebind data contracts, permissions, UI shell, storage, and deployment to the HyperTwist architecture. Best first pairing order: HactarCE/Hyperspeedcube, cubing/cubing.js, tao-yu/Alg-Trainer. Repurpose here means Repurpose here means: turn it into a higher-dimensional renderer/simulator donor and shared interaction grammar for HyperTwist and long-horizon VectorShell. Source inspection should focus on Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, tao-yu/Alg-Trainer. Primary URL: https://github.com/Hypercubers/hypercubing.xyz
|
||||
|
||||
**kubernetes/ingress-nginx** is a HyperTwist-first portfolio candidate in **Donor Bench**, currently treated as **donor bench** with primary archetype **subsystem donor**. It is relevant because it contributes kubernetes/ingress-nginx (Apache 2.0) — Ingress controller. API gateway visualization as wormholes. Medium-high value. | kubernetes/ingress-nginx – API gateway wormholescpp | kubernetes/ingress-nginx – https://github.com/kubernetes/ingre... to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Repurpose selected subsystems rather than the whole product. Mine the repo for scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition; keep what materially shortens build time, but rebind data contracts, permissions, UI shell, storage, and deployment to the HyperTwist architecture. Best first pairing order: tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect parsers and language adapters; graph schema and storage; incremental indexing/update logic; layout engine; query API; export/import formats; test fixtures for graph correctness.. The strongest currently noted combinations are project-local anchor, shared portfolio utility, cross-project transfer candidate. Primary URL: https://github.com/kubernetes/ingress-nginx
|
||||
|
||||
**Aarav2709/KubeTimr** is a HyperTwist-first portfolio candidate in **Donor Bench**, currently treated as **donor bench** with primary archetype **subsystem donor**. It is relevant because it contributes Aarav2709/KubeTimr — MIT — Keyboard-first offline timer. | Aarav2709/KubeTimr — MIT — Offline timer. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Repurpose selected subsystems rather than the whole product. Mine the repo for scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition; keep what materially shortens build time, but rebind data contracts, permissions, UI shell, storage, and deployment to the HyperTwist architecture. Best first pairing order: tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.. The strongest currently noted combinations are tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer. Primary URL: https://github.com/Aarav2709/KubeTimr
|
||||
|
||||
**grafana/alloy** is a HyperTwist-first portfolio candidate in **Donor Bench**, currently treated as **donor bench** with primary archetype **subsystem donor**. It is relevant because it contributes grafana/alloy (Apache 2.0) – OpenTelemetry Collector distribution. Observability pipelines as wormhole flows. | grafana/alloy – https://github.com/grafana/alloy – Apache-2.0 – OpenTelemetry Collector. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Repurpose selected subsystems rather than the whole product. Mine the repo for scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition; keep what materially shortens build time, but rebind data contracts, permissions, UI shell, storage, and deployment to the HyperTwist architecture. Best first pairing order: tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect topology/service schema; collectors/agents; auth/integration adapters; caching/state sync; deployment/runtime abstractions; metrics/event correlation; config layering.. The strongest currently noted combinations are project-local anchor, shared portfolio utility, cross-project transfer candidate. Primary URL: https://github.com/grafana/alloy
|
||||
|
||||
**roice3/MagicTile** is a HyperTwist-first portfolio candidate in **Donor Bench**, currently treated as **donor bench** with primary archetype **subsystem donor**. It is relevant because it contributes Non-euclidean Rubik's Cube Analogues to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Repurpose selected subsystems rather than the whole product. Mine the repo for scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition; keep what materially shortens build time, but rebind data contracts, permissions, UI shell, storage, and deployment to the HyperTwist architecture. Best first pairing order: tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect topology/service schema; collectors/agents; auth/integration adapters; caching/state sync; deployment/runtime abstractions; metrics/event correlation; config layering.. The strongest currently noted combinations are project-local anchor, shared portfolio utility, cross-project transfer candidate. Primary URL: https://github.com/roice3/MagicTile
|
||||
|
||||
**Kong/kubernetes-ingress-controller** is a HyperTwist-first portfolio candidate in **Donor Bench**, currently treated as **donor bench** with primary archetype **subsystem donor**. It is relevant because it contributes Kong/kubernetes-ingress-controller – https://github.com/Kong/kubernetes-ingress-controller – Apache-2.0 – Kong for Kubernetes. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Repurpose selected subsystems rather than the whole product. Mine the repo for scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition; keep what materially shortens build time, but rebind data contracts, permissions, UI shell, storage, and deployment to the HyperTwist architecture. Best first pairing order: tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect topology/service schema; collectors/agents; auth/integration adapters; caching/state sync; deployment/runtime abstractions; metrics/event correlation; config layering.. The strongest currently noted combinations are project-local anchor, shared portfolio utility, cross-project transfer candidate. Primary URL: https://github.com/Kong/kubernetes-ingress-controller
|
||||
|
||||
**cubing/alg.js** is a HyperTwist-first portfolio candidate in **Donor Bench**, currently treated as **Donor Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/alg.js
|
||||
|
||||
**cubing/scrambles** is a HyperTwist-first portfolio candidate in **Donor Bench**, currently treated as **Donor Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/scrambles
|
||||
|
||||
**cubing/twisty.js** is a HyperTwist-first portfolio candidate in **Donor Bench**, currently treated as **Donor Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/twisty.js
|
||||
|
||||
**cubing/qqTimer** is a HyperTwist-first portfolio candidate in **Donor Bench**, currently treated as **Donor Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/qqTimer
|
||||
|
||||
**usestrix/strix** is a HyperTwist-first portfolio candidate in **Donor Bench**, currently treated as **donor bench** with primary archetype **subsystem donor**. It is relevant because it contributes Open-source AI hackers to find and fix your app’s vulnerabilities. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Repurpose selected subsystems rather than the whole product. Mine the repo for scan engine, template/rule packs, protocol fingerprinting, job runner, result schema, enrichment pipeline, attack-path graph, evidence output; keep what materially shortens build time, but rebind data contracts, permissions, UI shell, storage, and deployment to the HyperTwist architecture. Best first pairing order: HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Repurpose here means Repurpose here means: turn it into a scan microservice, attack-surface enrichment job, or graph overlay feeding VectorShell. Source inspection should focus on Inspect scan engine; rule/template packs; protocol handlers; result schema normalization; auth/session handling; enrichment/correlation pipeline; evidence/report exporters; distributed runner support.. The strongest currently noted combinations are project-local anchor, shared portfolio utility, cross-project transfer candidate. Primary URL: https://github.com/usestrix/strix
|
||||
|
||||
**Eronred/aso-skills** is a HyperTwist-first portfolio candidate in **Donor Bench**, currently treated as **donor bench** with primary archetype **workflow donor**. It is relevant because it contributes AI agent skills for App Store Optimization (ASO) and mobile app marketing. Built for indie developers, app marketers, and growth teams who want Cursor, Claude Code, or any Agent Skills-compatible AI assistant to help with keyword researc... to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Repurpose selected subsystems rather than the whole product. Mine the repo for planner/state machine, tool registry, MCP adapters, memory model, task graph, provider abstraction, approvals, agent telemetry; keep what materially shortens build time, but rebind data contracts, permissions, UI shell, storage, and deployment to the HyperTwist architecture. Best first pairing order: HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Repurpose here means Repurpose here means: turn it into a portfolio agent service, MCP adapter, tool-calling layer, or planner/memory donor. Source inspection should focus on Inspect planner/task graph; provider abstraction; tool registry or MCP bridges; memory/state schema; approvals/retries; telemetry/event bus; plugin or skill loading hooks.. The strongest currently noted combinations are project-local anchor, shared portfolio utility, cross-project transfer candidate. Primary URL: https://github.com/Eronred/aso-skills
|
||||
|
||||
**HKUDS/DeepTutor** is a HyperTwist-first portfolio candidate in **Donor Bench**, currently treated as **donor bench** with primary archetype **workflow donor**. It is relevant because it contributes "DeepTutor: AI-Powered Personalized Learning Assistant" to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Repurpose selected subsystems rather than the whole product. Mine the repo for planner/state machine, tool registry, MCP adapters, memory model, task graph, provider abstraction, approvals, agent telemetry; keep what materially shortens build time, but rebind data contracts, permissions, UI shell, storage, and deployment to the HyperTwist architecture. Best first pairing order: HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Repurpose here means Repurpose here means: turn it into a portfolio agent service, MCP adapter, tool-calling layer, or planner/memory donor. Source inspection should focus on Inspect planner/task graph; provider abstraction; tool registry or MCP bridges; memory/state schema; approvals/retries; telemetry/event bus; plugin or skill loading hooks.. The strongest currently noted combinations are project-local anchor, shared portfolio utility, cross-project transfer candidate. Primary URL: https://github.com/HKUDS/DeepTutor
|
||||
|
||||
**PostHog/posthog** is a HyperTwist-first portfolio candidate in **Donor Bench**, currently treated as **donor bench** with primary archetype **subsystem donor**. It is relevant because it contributes 🦔 PostHog is an all-in-one developer platform for building successful products. We offer product analytics, web analytics, session replay, error tracking, feature flags, experimentation, surveys, data warehouse, a CDP, and an AI product ... to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Repurpose selected subsystems rather than the whole product. Mine the repo for telemetry/event schema, API clients, orchestration hooks, dashboards, service integration, deployment/runtime adapters, queues, secrets/config; keep what materially shortens build time, but rebind data contracts, permissions, UI shell, storage, and deployment to the HyperTwist architecture. Best first pairing order: HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Repurpose here means Repurpose here means: turn it into an integration layer, telemetry spine, service dashboard, or control-plane donor. Source inspection should focus on Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.. The strongest currently noted combinations are kkoomen/qbr, vivaansinghvi07/rubix-cube-solver, cubing/cubing.js. Primary URL: https://github.com/PostHog/posthog
|
||||
|
||||
**pocket-id/pocket-id** is a HyperTwist-first portfolio candidate in **Donor Bench**, currently treated as **donor bench** with primary archetype **subsystem donor**. It is relevant because it contributes A simple and easy-to-use OIDC provider that allows users to authenticate with their passkeys to your services. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Repurpose selected subsystems rather than the whole product. Mine the repo for telemetry/event schema, API clients, orchestration hooks, dashboards, service integration, deployment/runtime adapters, queues, secrets/config; keep what materially shortens build time, but rebind data contracts, permissions, UI shell, storage, and deployment to the HyperTwist architecture. Best first pairing order: HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Repurpose here means Repurpose here means: turn it into an integration layer, telemetry spine, service dashboard, or control-plane donor. Source inspection should focus on Inspect topology/service schema; collectors/agents; auth/integration adapters; caching/state sync; deployment/runtime abstractions; metrics/event correlation; config layering.. The strongest currently noted combinations are project-local anchor, shared portfolio utility, cross-project transfer candidate. Primary URL: https://github.com/pocket-id/pocket-id
|
||||
|
||||
**sheepbox8646/ChatTutor** is a HyperTwist-first portfolio candidate in **Donor Bench**, currently treated as **donor bench** with primary archetype **subsystem donor**. It is relevant because it contributes 本项目已转移到 https://github.com/HugeCatLab/ChatTutor | This project has been transfer to https://github.com/HugeCatLab/ChatTutor to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Repurpose selected subsystems rather than the whole product. Mine the repo for realtime transport, rooms/threads, presence, access control, notification model, sync conflict handling, file/link embeds; keep what materially shortens build time, but rebind data contracts, permissions, UI shell, storage, and deployment to the HyperTwist architecture. Best first pairing order: HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Repurpose here means Repurpose here means: turn it into a realtime rooms/presence/comments layer tied to the main workspace or shell. Source inspection should focus on Inspect presence/event model; transport layer; permissions/auth; bot/plugin hooks; storage schema; import/export and integration webhooks.. The strongest currently noted combinations are project-local anchor, shared portfolio utility, cross-project transfer candidate. Primary URL: https://github.com/sheepbox8646/ChatTutor
|
||||
|
||||
**truongduy2611/app-store-preflight-skills** is a HyperTwist-first portfolio candidate in **Donor Bench**, currently treated as **donor bench** with primary archetype **workflow donor**. It is relevant because it contributes AI agent skill to scan iOS/macOS projects for App Store rejection patterns before submission to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Repurpose selected subsystems rather than the whole product. Mine the repo for planner/state machine, tool registry, MCP adapters, memory model, task graph, provider abstraction, approvals, agent telemetry; keep what materially shortens build time, but rebind data contracts, permissions, UI shell, storage, and deployment to the HyperTwist architecture. Best first pairing order: HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Repurpose here means Repurpose here means: turn it into a portfolio agent service, MCP adapter, tool-calling layer, or planner/memory donor. Source inspection should focus on Inspect planner/task graph; provider abstraction; tool registry or MCP bridges; memory/state schema; approvals/retries; telemetry/event bus; plugin or skill loading hooks.. The strongest currently noted combinations are project-local anchor, shared portfolio utility, cross-project transfer candidate. Primary URL: https://github.com/truongduy2611/app-store-preflight-skills
|
||||
|
||||
|
||||
## Merge Bench
|
||||
|
||||
**cutelyaware/magiccube4d** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes Automatically exported from code.google.com/p/magiccube4d to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a hypercubing / nD simulation subsystem for HyperTwist. Preserve the strongest existing pieces — nD state model, move notation, renderer, projection controls, solver/traversal logic, puzzle serialization, replay — and expose them behind a portfolio-stable interface. Wire first into HactarCE/Hyperspeedcube, then into cubing/cubing.js for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a higher-dimensional renderer/simulator donor and shared interaction grammar for HyperTwist and long-horizon VectorShell. Source inspection should focus on Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, tao-yu/Alg-Trainer. Primary URL: https://github.com/cutelyaware/magiccube4d/tree/master
|
||||
|
||||
**roice3/Magic120Cell** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes 4D Megaminx Analogue to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a hypercubing / nD simulation subsystem for HyperTwist. Preserve the strongest existing pieces — nD state model, move notation, renderer, projection controls, solver/traversal logic, puzzle serialization, replay — and expose them behind a portfolio-stable interface. Wire first into HactarCE/Hyperspeedcube, then into cubing/cubing.js for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a higher-dimensional renderer/simulator donor and shared interaction grammar for HyperTwist and long-horizon VectorShell. Source inspection should focus on Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, tao-yu/Alg-Trainer. Primary URL: https://github.com/roice3/Magic120Cell
|
||||
|
||||
**roice3/MagicCube5D** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes 5D Rubik's Cube Analogue to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a hypercubing / nD simulation subsystem for HyperTwist. Preserve the strongest existing pieces — nD state model, move notation, renderer, projection controls, solver/traversal logic, puzzle serialization, replay — and expose them behind a portfolio-stable interface. Wire first into HactarCE/Hyperspeedcube, then into cubing/cubing.js for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a higher-dimensional renderer/simulator donor and shared interaction grammar for HyperTwist and long-horizon VectorShell. Source inspection should focus on Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, tao-yu/Alg-Trainer. Primary URL: https://github.com/roice3/MagicCube5D
|
||||
|
||||
**molgenis/Graph2VR** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **legacy comparator**. It is relevant because it contributes molgenis/Graph2VR — https://github.com/molgenis/Graph2VR | molgenis/Graph2VR — MIT — Floating 3D graph VR. | poliva/cubedex, tao-yu/Alg-Trainer, kkoomen/qbr, vivaansinghvi07/rubix-cube-solver, NuiLab/code-vr, molgenis/Graph2VR (core perm... to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect parsers and language adapters; graph schema and storage; incremental indexing/update logic; layout engine; query API; export/import formats; test fixtures for graph correctness.. The strongest currently noted combinations are project-local anchor, shared portfolio utility, cross-project transfer candidate. Primary URL: https://github.com/molgenis/Graph2VR
|
||||
|
||||
**aMonteSl/Code-XR** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes aMonteSl/Code-XR — https://github.com/aMonteSl/CodeXR (VS Code extension) | aMonteSl/Code-XR — MIT — XR code metrics viz. | poliva/cubedex, tao-yu/Alg-Trainer, kkoomen/qbr, vivaansinghvi07/rubix-cube-solver, NuiLab/code-vr, molgenis/Grap... to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.. The strongest currently noted combinations are kkoomen/qbr, vivaansinghvi07/rubix-cube-solver, cubing/cubing.js. Primary URL: https://github.com/aMonteSl/Code-XR
|
||||
|
||||
**brianpeiris/RiftSketch** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes brianpeiris/RiftSketch — https://github.com/brianpeiris/RiftSketch | brianpeiris/RiftSketch — MIT — WebVR live coding. | poliva/cubedex, tao-yu/Alg-Trainer, kkoomen/qbr, vivaansinghvi07/rubix-cube-solver, NuiLab/code-vr, molgenis/Graph2V... to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.. The strongest currently noted combinations are kkoomen/qbr, vivaansinghvi07/rubix-cube-solver, cubing/cubing.js. Primary URL: https://github.com/brianpeiris/RiftSketch
|
||||
|
||||
**MathewKJ2048/Rubiks-cube-simulator** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes MathewKJ2048/Rubiks-cube-simulator — GPL-3.0 — Java Swing simulator/solver. | MathewKJ2048/Rubiks-cube-simulator — GPL-3.0. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.. The strongest currently noted combinations are tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer. Primary URL: https://github.com/MathewKJ2048/Rubiks-cube-simulator
|
||||
|
||||
**NuiLab/code-vr** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes NuiLab/code-vr — (license permissive per repo) — VR codebase explorer. | poliva/cubedex, tao-yu/Alg-Trainer, kkoomen/qbr, vivaansinghvi07/rubix-cube-solver, NuiLab/code-vr, molgenis/Graph2VR (core permissive parts), brianpeiris/RiftSketc... to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.. The strongest currently noted combinations are kkoomen/qbr, vivaansinghvi07/rubix-cube-solver, cubing/cubing.js. Primary URL: https://github.com/NuiLab/code-vr
|
||||
|
||||
**ShellPuppy/RCube** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes ShellPuppy/RCube — GPL-3.0 — Solver for arbitrarily large cubes. | ShellPuppy/RCube — GPL-3.0 (large-cube solver). to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.. The strongest currently noted combinations are tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer. Primary URL: https://github.com/ShellPuppy/RCube
|
||||
|
||||
**abunickabhi/5style-Trainer** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes abunickabhi/5style-Trainer — MIT — 5-style BLD trainer (fork of Alg-Trainer). | abunickabhi/5style-Trainer — MIT (BLD extension). to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.. The strongest currently noted combinations are tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer. Primary URL: https://github.com/abunickabhi/5style-Trainer
|
||||
|
||||
**brownan/Rubiks-Cube-Solver** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes brownan/Rubiks-Cube-Solver — GPL-3.0 — Optimal pattern-database solver. | brownan/Rubiks-Cube-Solver — GPL-3.0. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.. The strongest currently noted combinations are tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer. Primary URL: https://github.com/brownan/Rubiks-Cube-Solver
|
||||
|
||||
**nealmick/Cube** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes nealmick/Cube — GPL-3.0 — Solver + visualizer. | nealmick/Cube — GPL-3.0. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect parsers and language adapters; graph schema and storage; incremental indexing/update logic; layout engine; query API; export/import formats; test fixtures for graph correctness.. The strongest currently noted combinations are project-local anchor, shared portfolio utility, cross-project transfer candidate. Primary URL: https://github.com/nealmick/Cube
|
||||
|
||||
**newyork-anthonyng/rubiks-cross-trainer** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes newyork-anthonyng/rubiks-cross-trainer — MIT — Cross trainer library (scramble generator). | newyork-anthonyng/rubiks-cross-trainer — MIT. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.. The strongest currently noted combinations are tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer. Primary URL: https://github.com/newyork-anthonyng/rubiks-cross-trainer
|
||||
|
||||
**vwcwong/CubeSim** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes vwcwong/CubeSim — GPL-3.0 — Python/Pygame simulator + solver. | vwcwong/CubeSim — GPL-3.0 — Python simulator. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.. The strongest currently noted combinations are tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer. Primary URL: https://github.com/vwcwong/CubeSim
|
||||
|
||||
**AviKaufman/Rubix-cube-trainer** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes Rubix-cube-trainer (AviKaufman/Rubix-cube-trainer) to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.. The strongest currently noted combinations are tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer. Primary URL: https://github.com/AviKaufman/Rubix-cube-trainer
|
||||
|
||||
**alinen/cube** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes Various smaller ones like alinen/cube (basic trainer + solver): https://github.com/alinen/cube. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.. The strongest currently noted combinations are tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer. Primary URL: https://github.com/alinen/cube
|
||||
|
||||
**ambisinister/blindsolve** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes For blind solving memo: https://github.com/ambisinister/blindsolve (virtual blind memo trainer). to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.. The strongest currently noted combinations are tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer. Primary URL: https://github.com/ambisinister/blindsolve
|
||||
|
||||
**efrantar/rob-twophase** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes efrantar/rob-twophase — GPL-3.0 — High-speed robot solver. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.. The strongest currently noted combinations are tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer. Primary URL: https://github.com/efrantar/rob-twophase
|
||||
|
||||
**onionhoney/roux-trainers** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes Roux-Trainers (onionhoney/roux-trainers) to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.. The strongest currently noted combinations are tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer. Primary URL: https://github.com/onionhoney/roux-trainers
|
||||
|
||||
**yakupbilen/drl-rubiks-cube** is a HyperTwist-first portfolio candidate in **Merge Bench**, currently treated as **active merge-set candidate** with primary archetype **subsystem donor**. It is relevant because it contributes yakupbilen/drl-rubiks-cube — MIT — RL solver with PyQt5 + webcam input. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange. Repurpose here means Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist. Source inspection should focus on Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.. The strongest currently noted combinations are kkoomen/qbr, vivaansinghvi07/rubix-cube-solver, cubing/cubing.js. Primary URL: https://github.com/yakupbilen/drl-rubiks-cube
|
||||
|
||||
|
||||
## Reserve Bench
|
||||
|
||||
**HactarCE/2x2x2x2-Scrambler** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/2x2x2x2-Scrambler
|
||||
|
||||
**HactarCE/ajfarkas.dev** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/ajfarkas.dev
|
||||
|
||||
**HactarCE/alt-vim-keys** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/alt-vim-keys
|
||||
|
||||
**HactarCE/approx_collections** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/approx_collections
|
||||
|
||||
**HactarCE/async_python_examples** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/async_python_examples
|
||||
|
||||
**HactarCE/axiom** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/axiom
|
||||
|
||||
**HactarCE/bevy_turborand** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/bevy_turborand
|
||||
|
||||
**HactarCE/bitvec** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/bitvec
|
||||
|
||||
**HactarCE/bracket-lib** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/bracket-lib
|
||||
|
||||
**HactarCE/chess** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/chess
|
||||
|
||||
**HactarCE/clap** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/clap
|
||||
|
||||
**HactarCE/const-random** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/const-random
|
||||
|
||||
**HactarCE/crossbeam** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/crossbeam
|
||||
|
||||
**HactarCE/discordrb** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/discordrb
|
||||
|
||||
**HactarCE/dotfiles** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/dotfiles
|
||||
|
||||
**HactarCE/druid** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/druid
|
||||
|
||||
**HactarCE/egui** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/egui
|
||||
|
||||
**HactarCE/egui_plot** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/egui_plot
|
||||
|
||||
**HactarCE/egui_wgpu** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/egui_wgpu
|
||||
|
||||
**HactarCE/egui_winit** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/egui_winit
|
||||
|
||||
**HactarCE/emacs.d** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/emacs.d
|
||||
|
||||
**HactarCE/ggez** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/ggez
|
||||
|
||||
**HactarCE/git2-rs** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/git2-rs
|
||||
|
||||
**HactarCE/glium** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/glium
|
||||
|
||||
**HactarCE/glyphon** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/glyphon
|
||||
|
||||
**HactarCE/gpui** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/gpui
|
||||
|
||||
**HactarCE/iced** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/iced
|
||||
|
||||
**HactarCE/image** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/image
|
||||
|
||||
**HactarCE/lyon** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/lyon
|
||||
|
||||
**HactarCE/macroquad** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/macroquad
|
||||
|
||||
**HactarCE/mint** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/mint
|
||||
|
||||
**HactarCE/nalgebra** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/nalgebra
|
||||
|
||||
**HactarCE/nannou** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/nannou
|
||||
|
||||
**HactarCE/ncollide** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/ncollide
|
||||
|
||||
**HactarCE/notan** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/notan
|
||||
|
||||
**HactarCE/nphysics** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/nphysics
|
||||
|
||||
**HactarCE/pixels** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/pixels
|
||||
|
||||
**HactarCE/plotters** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/plotters
|
||||
|
||||
**HactarCE/rapier** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/rapier
|
||||
|
||||
**HactarCE/rayon** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/rayon
|
||||
|
||||
**HactarCE/rusttype** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/rusttype
|
||||
|
||||
**HactarCE/skia-safe** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/skia-safe
|
||||
|
||||
**HactarCE/taffy** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/taffy
|
||||
|
||||
**HactarCE/tiny-skia** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/tiny-skia
|
||||
|
||||
**HactarCE/tokio** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/tokio
|
||||
|
||||
**HactarCE/tracing** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/tracing
|
||||
|
||||
**HactarCE/vello** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/vello
|
||||
|
||||
**HactarCE/vello_encoding** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/vello_encoding
|
||||
|
||||
**HactarCE/vulkano** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/vulkano
|
||||
|
||||
**HactarCE/wgpu** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/wgpu
|
||||
|
||||
**HactarCE/wgpu_glyph** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/wgpu_glyph
|
||||
|
||||
**HactarCE/winit** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/winit
|
||||
|
||||
**HactarCE/zed** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/HactarCE/zed
|
||||
|
||||
**cubing/Cubing-Test** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/Cubing-Test
|
||||
|
||||
**cubing/benchmark** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/benchmark
|
||||
|
||||
**cubing/cubing-aframe** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-aframe
|
||||
|
||||
**cubing/cubing-angular** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-angular
|
||||
|
||||
**cubing/cubing-asciidoc** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-asciidoc
|
||||
|
||||
**cubing/cubing-babylon** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-babylon
|
||||
|
||||
**cubing/cubing-bevy** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-bevy
|
||||
|
||||
**cubing/cubing-canvas** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-canvas
|
||||
|
||||
**cubing/cubing-cpp** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-cpp
|
||||
|
||||
**cubing/cubing-css** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-css
|
||||
|
||||
**cubing/cubing-csv** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-csv
|
||||
|
||||
**cubing/cubing-dart** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-dart
|
||||
|
||||
**cubing/cubing-dotnet** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-dotnet
|
||||
|
||||
**cubing/cubing-flutter** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-flutter
|
||||
|
||||
**cubing/cubing-go** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-go
|
||||
|
||||
**cubing/cubing-godot** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-godot
|
||||
|
||||
**cubing/cubing-html** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-html
|
||||
|
||||
**cubing/cubing-java** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-java
|
||||
|
||||
**cubing/cubing-js** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-js
|
||||
|
||||
**cubing/cubing-json** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-json
|
||||
|
||||
**cubing/cubing-kotlin** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-kotlin
|
||||
|
||||
**cubing/cubing-latex** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-latex
|
||||
|
||||
**cubing/cubing-markdown** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-markdown
|
||||
|
||||
**cubing/cubing-php** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-php
|
||||
|
||||
**cubing/cubing-playcanvas** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-playcanvas
|
||||
|
||||
**cubing/cubing-py** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-py
|
||||
|
||||
**cubing/cubing-react** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-react
|
||||
|
||||
**cubing/cubing-rs** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-rs
|
||||
|
||||
**cubing/cubing-ruby** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-ruby
|
||||
|
||||
**cubing/cubing-svelte** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-svelte
|
||||
|
||||
**cubing/cubing-svg** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-svg
|
||||
|
||||
**cubing/cubing-swift** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-swift
|
||||
|
||||
**cubing/cubing-three** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-three
|
||||
|
||||
**cubing/cubing-toml** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-toml
|
||||
|
||||
**cubing/cubing-ts** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-ts
|
||||
|
||||
**cubing/cubing-unity** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-unity
|
||||
|
||||
**cubing/cubing-vue** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-vue
|
||||
|
||||
**cubing/cubing-wasm** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-wasm
|
||||
|
||||
**cubing/cubing-webgl** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-webgl
|
||||
|
||||
**cubing/cubing-webgpu** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-webgpu
|
||||
|
||||
**cubing/cubing-webxr** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-webxr
|
||||
|
||||
**cubing/cubing-xml** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-xml
|
||||
|
||||
**cubing/cubing-yaml** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing-yaml
|
||||
|
||||
**cubing/cubing.github.com** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing.github.com
|
||||
|
||||
**cubing/cubing.net** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing.net
|
||||
|
||||
**cubing/cubing.org** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/cubing.org
|
||||
|
||||
**cubing/experiments** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/experiments
|
||||
|
||||
**cubing/logo** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/logo
|
||||
|
||||
**cubing/mark2** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/mark2
|
||||
|
||||
**cubing/playground** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/playground
|
||||
|
||||
**cubing/vscode** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/vscode
|
||||
|
||||
**cubing/wrc-proposal** is a HyperTwist-first portfolio candidate in **Reserve Bench**, currently treated as **Reserve Bench** with primary archetype **puzzle_simulation_training_donor**. It is relevant because it contributes HyperTwist family. Likely value lies in puzzle logic, scrambler design, algorithm representations, n-dimensional geometry, rendering, bindings, or XR/game-engine surfaces relevant to hypercube and cube-training workflows. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training. Repurpose here means Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters. Source inspection should focus on Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.. The strongest currently noted combinations are HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Primary URL: https://github.com/cubing/wrc-proposal
|
||||
|
||||
|
||||
## Exclude Current Horizon
|
||||
|
||||
**Rich-Harris/toofer** is a HyperTwist-first portfolio candidate in **Exclude Current Horizon**, currently treated as **speculative reserve** with primary archetype **future option**. It is relevant because it contributes Local-first, web-based two factor authenticator app to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Exclude from direct integration because visible fit is weaker, but still audit for hidden donor value in undocumented subsystems, APIs, data model, hidden admin/dev tools, import/export paths, plugin hooks, analytics hooks. Promote only if source inspection uncovers an unusually strong engine, plugin system, or UI/canvas/analytics primitive that outperforms anchors such as HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Repurpose here means No direct portfolio fit from visible metadata. Still inspect whether the code hides a reusable subsystem suggested by the repo description, examples, or tests. Source inspection should focus on Inspect package/module map; entrypoints; config and schema files; adapters/integrations; persistence model; tests/examples; hidden feature flags; plugin hooks.. The strongest currently noted combinations are project-local anchor, shared portfolio utility, cross-project transfer candidate. Primary URL: https://github.com/Rich-Harris/toofer
|
||||
|
||||
**rzhao271/MC3D** is a HyperTwist-first portfolio candidate in **Exclude Current Horizon**, currently treated as **speculative reserve** with primary archetype **future option**. It is relevant because it contributes A reupload of David Vanderschel's MC3D program to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Exclude from direct integration because visible fit is weaker, but still audit for hidden donor value in undocumented subsystems, APIs, data model, hidden admin/dev tools, import/export paths, plugin hooks, analytics hooks. Promote only if source inspection uncovers an unusually strong engine, plugin system, or UI/canvas/analytics primitive that outperforms anchors such as HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Repurpose here means No direct portfolio fit from visible metadata. Still inspect whether the code hides a reusable subsystem suggested by the repo description, examples, or tests. Source inspection should focus on Inspect package/module map; entrypoints; config and schema files; adapters/integrations; persistence model; tests/examples; hidden feature flags; plugin hooks.. The strongest currently noted combinations are project-local anchor, shared portfolio utility, cross-project transfer candidate. Primary URL: https://github.com/rzhao271/MC3D
|
||||
|
||||
**sethcottle/littlelink** is a HyperTwist-first portfolio candidate in **Exclude Current Horizon**, currently treated as **speculative reserve** with primary archetype **future option**. It is relevant because it contributes A lightweight DIY Linktree alternative. to the product’s dual identity as both a physical-cube coaching environment and a higher-dimensional hypercubing platform. In practical product terms, the current board expects HyperTwist to use this repo through the following realization path: Exclude from direct integration because visible fit is weaker, but still audit for hidden donor value in undocumented subsystems, APIs, data model, hidden admin/dev tools, import/export paths, plugin hooks, analytics hooks. Promote only if source inspection uncovers an unusually strong engine, plugin system, or UI/canvas/analytics primitive that outperforms anchors such as HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr. Repurpose here means No direct portfolio fit from visible metadata. Still inspect whether the code hides a reusable subsystem suggested by the repo description, examples, or tests. Source inspection should focus on Inspect package/module map; entrypoints; config and schema files; adapters/integrations; persistence model; tests/examples; hidden feature flags; plugin hooks.. The strongest currently noted combinations are project-local anchor, shared portfolio utility, cross-project transfer candidate. Primary URL: https://github.com/sethcottle/littlelink
|
||||
|
||||
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,284 @@
|
|||
# HyperTwist Forgejo/Woodpecker Bootstrap And First Push
|
||||
|
||||
Last updated: `2026-04-25` (`Europe/Berlin`)
|
||||
|
||||
Purpose:
|
||||
|
||||
- give HyperTwist a product-specific CI/CD onboarding note without copying ScriptoriumAI's live sensitive VPS runbook wholesale
|
||||
- make the repository ready for first remote creation, first commit, first push, and first Woodpecker activation
|
||||
- define the minimum CI chain now, while leaving production deployment details deferred until a real HyperTwist host and secret set exist
|
||||
|
||||
Reference source:
|
||||
|
||||
- `C:\HyperTwist\docs\refs\FORGEJO_WOODPECKER_VPS_A_TO_Z_SENSITIVE_RUNBOOK.md`
|
||||
|
||||
## Current HyperTwist state
|
||||
|
||||
Verified on `2026-04-25`:
|
||||
|
||||
- local git repo exists:
|
||||
- `C:\HyperTwist\.git`
|
||||
- no git remote is configured yet
|
||||
- no HyperTwist Woodpecker config existed before this bootstrap pass
|
||||
- the working tree is still effectively an initial large untracked tree
|
||||
|
||||
Implication:
|
||||
|
||||
- HyperTwist is version-controlled locally
|
||||
- but it has not yet been inserted into a remote Forgejo + Woodpecker chain
|
||||
|
||||
## What is reusable from the ScriptoriumAI runbook
|
||||
|
||||
Reusable patterns:
|
||||
|
||||
- Forgejo as the canonical remote source
|
||||
- Woodpecker as the push-triggered CI control plane
|
||||
- builder-label separation from ops-only agents
|
||||
- `skip_clone: true` plus explicit `git clone` when the environment needs deterministic checkout behavior
|
||||
- keeping bootstrap CI separate from later deploy workflows
|
||||
- documenting secrets by class, not by assumption
|
||||
|
||||
## What is not reusable as-is
|
||||
|
||||
Do not copy these directly into HyperTwist:
|
||||
|
||||
- ScriptoriumAI domains
|
||||
- ScriptoriumAI secrets
|
||||
- ScriptoriumAI VPS paths
|
||||
- ScriptoriumAI deploy scripts
|
||||
- ScriptoriumAI production-host assumptions
|
||||
- ScriptoriumAI repo name or owner slug
|
||||
|
||||
HyperTwist needs its own:
|
||||
|
||||
- Forgejo repo path
|
||||
- Woodpecker repo activation
|
||||
- builder labels
|
||||
- deployment target
|
||||
- SSH secrets
|
||||
- production smoke path
|
||||
|
||||
## Current recommended insertion point
|
||||
|
||||
Use a two-step chain first.
|
||||
|
||||
Step 1:
|
||||
|
||||
- source control bootstrap
|
||||
- remote creation
|
||||
- first commit
|
||||
- first push
|
||||
- bootstrap CI only
|
||||
|
||||
Step 2 later:
|
||||
|
||||
- production deployment workflow
|
||||
- deploy secrets
|
||||
- smoke checks
|
||||
- rollback procedure
|
||||
|
||||
This is the correct order because HyperTwist does not yet have a documented production host or secret set.
|
||||
|
||||
## Minimum first-time chain
|
||||
|
||||
The current recommended chain is:
|
||||
|
||||
1. create the HyperTwist repo in Forgejo
|
||||
2. add `origin` locally
|
||||
3. create the first intentional commit
|
||||
4. push `main`
|
||||
5. enable the repo in Woodpecker
|
||||
6. let the bootstrap workflow validate the repository shape
|
||||
7. only after that, add deploy-specific workflows and secrets
|
||||
|
||||
## Recommended Forgejo repo shape
|
||||
|
||||
Suggested placeholder until the final namespace is chosen:
|
||||
|
||||
- owner: the real HyperTwist Forgejo namespace
|
||||
- repo: `hypertwist`
|
||||
|
||||
Canonical remote pattern:
|
||||
|
||||
```text
|
||||
git@<forgejo-host>:<owner>/hypertwist.git
|
||||
```
|
||||
|
||||
HTTPS clone pattern if needed:
|
||||
|
||||
```text
|
||||
https://<forgejo-host>/<owner>/hypertwist.git
|
||||
```
|
||||
|
||||
## First local commands
|
||||
|
||||
After the Forgejo repo exists, use:
|
||||
|
||||
```powershell
|
||||
git -C C:\HyperTwist remote add origin git@<forgejo-host>:<owner>/hypertwist.git
|
||||
git -C C:\HyperTwist branch -M main
|
||||
git -C C:\HyperTwist add <scoped-paths>
|
||||
git -C C:\HyperTwist commit -m "Bootstrap HyperTwist repo and CI"
|
||||
git -C C:\HyperTwist push -u origin main
|
||||
```
|
||||
|
||||
Important scoping rule:
|
||||
|
||||
- do not blindly commit the entire current working tree without an explicit first-commit scope decision
|
||||
- the repo currently contains research material, mirrors, docs, Unreal work, and auxiliary files in one large untracked tree
|
||||
- the first commit should be intentional
|
||||
|
||||
## Recommended initial tracked set
|
||||
|
||||
The current recommended first commit scope is:
|
||||
|
||||
- `C:\HyperTwist\.gitattributes`
|
||||
- `C:\HyperTwist\.gitignore`
|
||||
- `C:\HyperTwist\.woodpecker\hypertwist-bootstrap.yml`
|
||||
- `C:\HyperTwist\docs\**` except `C:\HyperTwist\docs\refs\**`
|
||||
- `C:\HyperTwist\scripts\**`
|
||||
- `C:\HyperTwist\logo\HyperTwist logo with 3D symbol.png`
|
||||
- `C:\HyperTwist\UnrealHyperTwist\UnrealHyperTwist.uproject`
|
||||
- `C:\HyperTwist\UnrealHyperTwist\Config\*.ini`
|
||||
- `C:\HyperTwist\UnrealHyperTwist\Source\UnrealHyperTwist\**`
|
||||
|
||||
This keeps the initial repository honest:
|
||||
|
||||
- first-party Unreal code is tracked
|
||||
- product-specific CI bootstrap is tracked
|
||||
- non-sensitive docs and workspace/bootstrap scripts are tracked
|
||||
- the primary product logo is tracked
|
||||
- external mirrors, bulky archives, and sensitive refs stay out
|
||||
|
||||
## Recommended initial exclusions
|
||||
|
||||
The following should stay out of the first commit unless separately curated later:
|
||||
|
||||
- `C:\HyperTwist\docs\refs\**`
|
||||
- `C:\HyperTwist\mirrors\**`
|
||||
- `C:\HyperTwist\zippedreposource\**`
|
||||
- the root archive and website-dump folders
|
||||
- `C:\HyperTwist\Schläfli symbol\**`
|
||||
- root one-off research/reference PDFs, WEBPs, and prompt files
|
||||
- `C:\HyperTwist\logo\Miscellaneous\**`
|
||||
- `C:\HyperTwist\UnrealHyperTwist\Plugins\**`
|
||||
- `C:\HyperTwist\UnrealHyperTwist\Binaries\**`
|
||||
- `C:\HyperTwist\UnrealHyperTwist\DerivedDataCache\**`
|
||||
- `C:\HyperTwist\UnrealHyperTwist\Intermediate\**`
|
||||
- `C:\HyperTwist\UnrealHyperTwist\Saved\**`
|
||||
- generated Visual Studio solutions and user files
|
||||
|
||||
This is a bootstrap boundary, not a claim that the excluded material is permanently unwanted.
|
||||
|
||||
## Bootstrap CI scope
|
||||
|
||||
The initial Woodpecker workflow added in this pass is bootstrap-only.
|
||||
|
||||
It proves:
|
||||
|
||||
- Forgejo webhook -> Woodpecker pipeline trigger
|
||||
- checkout works
|
||||
- the expected HyperTwist tree exists
|
||||
- key product folders are present
|
||||
|
||||
It does **not** yet prove:
|
||||
|
||||
- Unreal compilation
|
||||
- packaging
|
||||
- deployment
|
||||
- production smoke
|
||||
|
||||
## Added bootstrap workflow
|
||||
|
||||
New workflow path:
|
||||
|
||||
- `C:\HyperTwist\.woodpecker\hypertwist-bootstrap.yml`
|
||||
|
||||
Current purpose:
|
||||
|
||||
- explicit checkout using `CI_REPO_CLONE_URL`
|
||||
- verify:
|
||||
- `.git` checkout happened
|
||||
- `UnrealHyperTwist/UnrealHyperTwist.uproject` exists
|
||||
- `UnrealHyperTwist/Source/UnrealHyperTwist` exists
|
||||
- `docs` exists
|
||||
|
||||
Why this workflow is intentionally narrow:
|
||||
|
||||
- HyperTwist is not yet ready for honest deployment automation
|
||||
- the Unreal project currently has upstream plugin-rule collisions that block full editor-build verification
|
||||
- fake deploy stages would create noise, not progress
|
||||
|
||||
## Woodpecker activation sequence
|
||||
|
||||
Once the Forgejo repo is pushed:
|
||||
|
||||
1. open Woodpecker
|
||||
2. sync repos if needed
|
||||
3. enable the HyperTwist repo
|
||||
4. confirm the default branch is `main`
|
||||
5. trigger the bootstrap pipeline manually if the first push did not auto-run
|
||||
|
||||
## Builder labeling recommendation
|
||||
|
||||
Keep the same deployment discipline used elsewhere:
|
||||
|
||||
- bootstrap/build agents should have builder labels
|
||||
- ops-only agents should not accidentally pick up repo builds
|
||||
|
||||
Suggested initial labels for HyperTwist bootstrap:
|
||||
|
||||
- `role=builder`
|
||||
- `backend=local`
|
||||
|
||||
That matches the new bootstrap workflow and stays compatible with a future external builder host.
|
||||
|
||||
## What must be decided before production deployment is added
|
||||
|
||||
Before adding deploy steps, decide:
|
||||
|
||||
1. Forgejo host and owner namespace
|
||||
2. Woodpecker builder host
|
||||
3. HyperTwist production host
|
||||
4. deploy path
|
||||
5. SSH identity and known-hosts policy
|
||||
6. smoke endpoint or equivalent deployment-health check
|
||||
7. whether deployment is:
|
||||
- Windows-hosted
|
||||
- Linux/VPS-hosted
|
||||
- artifact-only in the first phase
|
||||
|
||||
## Current recommendation
|
||||
|
||||
Do not add a production deploy workflow yet.
|
||||
|
||||
Instead:
|
||||
|
||||
- get the repo remotely created
|
||||
- get the first intentional commit pushed
|
||||
- get bootstrap CI green
|
||||
- then add a second document for:
|
||||
- HyperTwist production topology
|
||||
- deploy secrets
|
||||
- deploy pipeline
|
||||
- smoke and rollback
|
||||
|
||||
## Immediate next operational move
|
||||
|
||||
After this document lands, the next operational task should be:
|
||||
|
||||
1. choose the real Forgejo namespace and repo URL
|
||||
2. add `origin`
|
||||
3. decide first-commit scope
|
||||
4. stage and commit that scope
|
||||
5. push `main`
|
||||
6. enable the repo in Woodpecker
|
||||
|
||||
At that point HyperTwist will be inserted into the version-control and CI chain honestly, without pretending the production deployment layer is already settled.
|
||||
|
||||
If the remote URL is still unknown, the safe order is:
|
||||
|
||||
1. make the initial scoped local commit on `main`
|
||||
2. wait for the real Forgejo repo path
|
||||
3. add `origin`
|
||||
4. push that already-scoped history
|
||||
3100
docs/ops/TOOL_ACCESS_AND_REFACTORING_LOG.md
Normal file
3100
docs/ops/TOOL_ACCESS_AND_REFACTORING_LOG.md
Normal file
File diff suppressed because it is too large
Load diff
100
docs/ops/project-file-setup-manual.codex.md
Normal file
100
docs/ops/project-file-setup-manual.codex.md
Normal file
|
|
@ -0,0 +1,100 @@
|
|||
# Codex Project File Setup Manual
|
||||
|
||||
This note records how `HyperTwist` should be represented in Visual Studio while the codebase is still being assembled.
|
||||
|
||||
## Current Rule
|
||||
|
||||
The repo-root `HyperTwist.vcxproj` should be treated as a lightweight workspace shell, not as the real application project.
|
||||
|
||||
It should not be used to pull in large repository trees such as:
|
||||
|
||||
- `mirrors/`
|
||||
- `node_modules/`
|
||||
- generated output such as `.vs/`, `x64/`, `Intermediate/`, `Binaries/`, `dist/`, `coverage/`
|
||||
- research, archives, downloads, or reference bundles
|
||||
|
||||
If the root `.vcxproj` turns into a giant file collector, Visual Studio indexing, Copilot context, RAM use, and build behavior all get worse.
|
||||
|
||||
## What To Do Now
|
||||
|
||||
While the architecture is still being decided:
|
||||
|
||||
- Keep the solution small and intentional.
|
||||
- Use the repo-root project only as a workspace placeholder or solution anchor.
|
||||
- Keep real implementation in real language/project folders.
|
||||
- Do not add vendored, mirrored, archived, or generated folders to the root `.vcxproj`.
|
||||
|
||||
## When To Create Real Projects
|
||||
|
||||
Create a real project only when the corresponding codebase actually exists.
|
||||
|
||||
### C++
|
||||
|
||||
Create or expand a real `.vcxproj` when there is an actual native code layout such as:
|
||||
|
||||
- `src/`
|
||||
- `include/`
|
||||
- `app/`
|
||||
- `engine/`
|
||||
|
||||
At that point the `.vcxproj` should include only first-party native source files and headers.
|
||||
|
||||
### C#
|
||||
|
||||
Create a `.csproj` when there is real C# application or library code. Let the `.csproj` represent the actual source tree instead of routing C# through the root `.vcxproj`.
|
||||
|
||||
### Node / TypeScript
|
||||
|
||||
Create an `.njsproj` only when there is a real frontend, tool, server, or plugin root with files such as:
|
||||
|
||||
- `package.json`
|
||||
- `src/`
|
||||
- `public/`
|
||||
- `tests/`
|
||||
|
||||
The Node project should point only at that app folder and should explicitly ignore `node_modules`, build output, caches, and mirrors.
|
||||
|
||||
### Rust
|
||||
|
||||
Use `Cargo.toml` as the source of truth. Do not force Rust code into a C++ project. When the crate layout is real, wire Visual Studio around the Rust crate deliberately.
|
||||
|
||||
### Unreal
|
||||
|
||||
If `HyperTwist` grows around Unreal, let Unreal-generated project structure remain the source of truth for Unreal modules and plugin code. Do not dump Unreal `Intermediate` or generated build output into the root `.vcxproj`.
|
||||
|
||||
## When To Ask Codex To Set It Up
|
||||
|
||||
Come back and ask for setup when one of these is true:
|
||||
|
||||
- the first real app folder has been created
|
||||
- the first real language-specific project exists
|
||||
- you want the multi-project solution updated cleanly
|
||||
- you want Copilot/Visual Studio indexing to recognize the app roots properly
|
||||
|
||||
Good examples:
|
||||
|
||||
- "Create a proper Node.js project for `ui/`."
|
||||
- "Turn `engine/src` and `engine/include` into the real C++ project."
|
||||
- "Add the Rust crate and keep it out of the root `.vcxproj`."
|
||||
- "Wire the Unreal plugin/tooling folders into the solution without indexing generated output."
|
||||
|
||||
## What Not To Do
|
||||
|
||||
- Do not use the repo-root `.vcxproj` as a catch-all for the entire repository.
|
||||
- Do not include `mirrors`, archives, downloaded reference material, or generated folders.
|
||||
- Do not rely on `Show All Files` plus a giant root project as the long-term structure.
|
||||
- Do not assume Visual Studio will "organically" infer the right architecture later if the placeholder project is already polluted.
|
||||
|
||||
## Practical Bootstrap Sequence
|
||||
|
||||
1. Decide the first real code roots.
|
||||
2. Create the real language-native project files for those roots only.
|
||||
3. Keep the repo-root project minimal.
|
||||
4. Exclude generated, mirrored, vendored, and research-only directories from indexing.
|
||||
5. Rebuild the solution index after structural changes.
|
||||
|
||||
## Short Version
|
||||
|
||||
Until the real code layout exists, keep `HyperTwist.vcxproj` minimal.
|
||||
|
||||
Once real C++, C#, Node/TypeScript, Rust, or Unreal code roots exist, ask Codex to wire those folders into proper project files instead of expanding the root workspace project.
|
||||
47
docs/repo_portfolio_unified_branch_seed_prompt_v6_3.md
Normal file
47
docs/repo_portfolio_unified_branch_seed_prompt_v6_3.md
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
# Branch Seed Prompt — Canonical v6.3
|
||||
|
||||
Treat this branch as a v6.3-governed portfolio session.
|
||||
|
||||
## Authority Order
|
||||
1. AGENTS.MD
|
||||
2. ARCHITECTURE.MD
|
||||
3. PRD.MD
|
||||
4. ROADMAP.MD
|
||||
5. API.MD
|
||||
6. LICENSETRACKING.MD
|
||||
7. SKILLS.MD
|
||||
8. repo_portfolio_unified_v6_3.xlsx
|
||||
9. repo_portfolio_unified_phase_g_v6_3.csv
|
||||
10. repo_portfolio_unified_operational_v6_3.csv
|
||||
11. repo_portfolio_unified_source_audit_v6_3.csv
|
||||
12. repo_portfolio_unified_vscode_packets_v6_3.csv
|
||||
13. repo_portfolio_unified_merger_matrix_v6_3.csv
|
||||
14. repo_portfolio_unified_cluster_narratives_v6_3.csv
|
||||
15. repo_portfolio_unified_copyleft_strategy_matrix_v6_3.csv
|
||||
16. repo_portfolio_unified_re_layer_matrix_v6_3.csv
|
||||
|
||||
## Session Rules
|
||||
- Licensing is non-gating.
|
||||
- Strong copyleft must be classified, not fear-filtered.
|
||||
- Preserve the distinction between foundations, donors, merge bench, reserve bench, comparators, and excluded-current-horizon.
|
||||
- Use ScriptoriumAI current implemented runtime as reality anchor.
|
||||
- Treat v6.3 as canonical; legacy packs are reference only.
|
||||
|
||||
## If auditing a repo
|
||||
Return:
|
||||
- implemented capability summary
|
||||
- hidden reusable modules
|
||||
- updated fit for VectorShell / HyperTwist / ScriptoriumAI
|
||||
- integration path
|
||||
- repurpose path
|
||||
- merger path
|
||||
- copyleft strategy
|
||||
- license uncertainty note
|
||||
- canonical ranking change note
|
||||
|
||||
## If generating code
|
||||
Obey:
|
||||
- clean-room UI boundary for ScriptoriumAI
|
||||
- Rust-first backend policy
|
||||
- C# only where additive advantage is real
|
||||
- Python only for specialist runtime islands
|
||||
13
docs/repo_portfolio_unified_cluster_narratives_v6_3.csv
Normal file
13
docs/repo_portfolio_unified_cluster_narratives_v6_3.csv
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
"cluster_tag","title","repo_count","candidate_core","realization_path","scope","donor_swarm","hidden_value_to_seek_in_source","cross_project_transfer","uncertainty","source_of_truth","v6_source_of_truth","v6_3_source_of_truth"
|
||||
"HT_browser_support","HyperTwist Browser Support Stack","21","ecomfe/zrender | KhronosGroup/glTF-Sample-Renderer | pmndrs/zustand | pmndrs/use-gesture | @react-spring/core","Start beneath the HT_browser_surface anchors: use zrender and glTF-Sample-Renderer as lower-level render substrates where needed, keep zustand and use-gesture as support utilities, use @react-spring/core as the motion kernel, then selectively attach package-level helpers like space-opera, render-fidelity-tools, model-viewer-effects, leva, and the narrower react-spring subpackages only where they materially shorten implementation time.","Lower-level browser support utilities, QA harnesses, editor helpers, motion internals, and fixture packs beneath the main browser surface anchors.","pissang/claygl | pissang/clay-viewer | google/model-viewer/packages/space-opera | google/model-viewer/packages/render-fidelity-tools | google/model-viewer/packages/model-viewer-effects | google/model-viewer/packages/modelviewer.dev | google/model-viewer/packages/shared-assets | pmndrs/react-postprocessing | pmndrs/three-stdlib | pmndrs/maath | pmndrs/leva | @react-spring/parallax | @react-spring/rafz | @react-spring/animated | @react-spring/shared | @react-spring/types","Hidden value often lives in lower-level render and loader seams, QA/golden harnesses, state and gesture kernels, motion internals, docs/demo tooling, and narrow fixture or asset-provenance flows rather than in visible demos alone.","VectorShell can reuse browser-side support utilities and editor helpers; ScriptoriumAI can reuse docs/demo and QA harness patterns where relevant.","Moderate uncertainty remains around which of these lower-level utilities deserve direct ownership versus thin dependency use; confirm during implementation planning.","Backfilled from canonized Markdown dossier pass on 2026-04-25.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"HT_browser_surface","HyperTwist Browser Surface Stack","12","mrdoob/three.js | pmndrs/react-three-fiber | pmndrs/xr | pmndrs/uikit | google/model-viewer | apache/echarts","Start with three.js and react-three-fiber as the browser 3D substrate, layer model-viewer and glTF viewer surfaces for inspection and preview, add pmndrs/xr and uikit for immersive and spatial UI, use echarts and echarts-gl for analytics and explainer views, then attach TalkingHead, drei, postprocessing, and react-spring as bounded presentation enhancers.","Browser-side companion surfaces for HyperTwist: analytics, 3D presentation, standards-aware asset preview, XR interaction, spatial UI, and embodied coach presentation.","met4citizen/TalkingHead | KhronosGroup/glTF-Sample-Viewer | ecomfe/echarts-gl | pmndrs/drei | pmndrs/postprocessing | pmndrs/react-spring","Hidden value often lives in renderer and event substrates, scene and asset inspection seams, XR session state, spatial UI layout, effect infrastructure, motion scheduling, and coach-friendly presentation patterns rather than in visible demos alone.","VectorShell can reuse browser-side 3D, XR, and spatial UI patterns; ScriptoriumAI can reuse reporting, presentation, and docs/demo-adjacent browser surfaces.","Moderate uncertainty remains around how many of these browser-side lanes HyperTwist should actively own versus keep as thin dependencies; confirm during source audit and implementation planning.","Backfilled from canonized Markdown dossier pass on 2026-04-24.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"HT_control_plane","HyperTwist Telemetry / Replay Governance","1","PostHog/posthog","Keep it outside the runtime core and mine it selectively for telemetry schemas, replay diagnostics, feature-flag governance, and vertical-slice service-boundary patterns, while excluding enterprise ee/ paths from direct reuse.","Telemetry, replay diagnostics, feature-flag governance, and control-plane donor material for HyperTwist.","PostHog/posthog","Hidden value often lives in replay deep-link and diagnostics flows, event-schema design, feature-flag CRUD and dependency handling, activity-log surfaces, and clean service boundaries rather than in the visible analytics shell.","VectorShell can borrow telemetry or feature-governance patterns; ScriptoriumAI can borrow replay/debugging and internal-tooling patterns where relevant.","Moderate uncertainty remains around how much of the mixed-license surface is actually worth retaining versus reimplementing behind a narrower first-party control plane.","Backfilled from canonized Markdown dossier pass on 2026-04-25.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"HT_cube_semantics","HyperTwist Classic Cube Semantics","4","cubing/cubing.js","Keep cubing/cubing.js as the boundary-sensitive anchor for classic-cubing semantics and rendering, then treat alg.js and twisty.js as focused clean-room companions and HactarCE/2x2x2x2-Scrambler as a compact hypercube-state donor rather than inheriting their shells wholesale.","Classic-cubing semantics, algorithm language, twisty playback/viewer behavior, and compact state-generation donors.","cubing/alg.js | cubing/twisty.js | HactarCE/2x2x2x2-Scrambler","Hidden value often lives in structured algorithm grammars, AST and traversal semantics, canonical move/state boundaries, playback and scrubber behavior, and compact solvable-state generation logic rather than in package shells alone.","VectorShell can borrow structured notation/render semantics; ScriptoriumAI can borrow twisty player and explainer patterns where relevant.","Moderate uncertainty remains around exactly which seams should stay direct under MPL versus be reimplemented from the restrictive donor rows; confirm during implementation planning.","Backfilled from canonized Markdown dossier pass on 2026-04-25.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"HT_cube_vision","HyperTwist Physical Cube Vision","8","kkoomen/qbr | vivaansinghvi07/rubix-cube-solver | cahidenes/rubiks-cube-solver | tentone/rubix-solver","Start with top core candidates, then merge donor modules in descending queue order, keeping source audit focused on hidden engines rather than UI chrome.","Extract camera calibration, cube-state reconstruction, replay, and AR handoff.","aMonteSl/CodeXR | brianpeiris/RiftSketch | NuiLab/code-vr | yakupbilen/drl-rubiks-cube","Hidden value often sits in calibration, preprocessing, stabilization, object/state reconstruction, replay artifacts, and camera-to-domain state pipelines that are not obvious from demos. Hidden value often sits in calibration, preprocessing, stabilization, object/state reconstruction, replay artifacts, and camera-to-domain state pipelines that are not obvious from demos.","VectorShell | ScriptoriumAI","High uncertainty where the cluster has many metadata-only repos or a large ""unclear"" slice; confirm by source audit before hard demotion.","Original global cluster narratives v3 retained","v6_unified_source_of_truth_pack","v6.3_final_source_of_truth"
|
||||
"HT_hyper_engine","HyperTwist Hypercubing Engine","7","HactarCE/Hyperspeedcube | kash/cubedesk","Start with top core candidates, then merge donor modules in descending queue order, keeping source audit focused on hidden engines rather than UI chrome.","Extract generalized puzzle/state/render abstractions for 3D–nD puzzles.","cutelyaware/magiccube4d | roice3/Magic120Cell | roice3/MagicCube5D | roice3/MagicTile | Hypercubers/hypercubing.xyz","Hidden value is likely in generalized puzzle/state representations, higher-dimensional transforms, notation systems, save formats, puzzle generators, and rendering abstractions. Hidden value is likely in generalized puzzle/state representations, higher-dimensional transforms, notation systems, save formats, puzzle generators, and rendering abstractions.","VectorShell | ScriptoriumAI","High uncertainty where the cluster has many metadata-only repos or a large ""unclear"" slice; confirm by source audit before hard demotion.","Original global cluster narratives v3 retained","v6_unified_source_of_truth_pack","v6.3_final_source_of_truth"
|
||||
"HT_solver_oracles","HyperTwist Solver Oracles","2","efrantar/rob-twophase | ShellPuppy/RCube","Keep both outside the core runtime and use them strictly as solver-oracle and large-N correctness benchmarks rather than as donor shells.","Solver-oracle and benchmarking lanes for correctness, robot metrics, and larger-cube planning reference.","efrantar/rob-twophase | ShellPuppy/RCube","Hidden value often lives in correctness oracles, large-N move metrics, robot-oriented constraints, and benchmark harness behavior rather than in any product shell.","VectorShell and ScriptoriumAI have little direct need here beyond occasional solver-oracle reference behavior.","Low-to-moderate uncertainty remains around whether any narrow algorithmic seam is worth later clean-room extraction beyond the benchmark/oracle role.","Backfilled from canonized Markdown dossier pass on 2026-04-25.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"HT_support_sidecars","HyperTwist Support Sidecars","2","screenpipe/screenpipe | remotion-dev/remotion","Keep both outside the core runtime. Use screenpipe selectively for capture/history/replay and permissions-aware support tooling, and use remotion selectively for bounded export and explainer rendering where the commercial terms are acceptable.","Support-plane sidecars for capture/history/replay and bounded media export.","screenpipe/screenpipe | remotion-dev/remotion","Hidden value often lives in lifecycle orchestration, permission-aware tooling, local storage and query seams, and export/render pipelines rather than in the visible demo shell.","VectorShell can borrow capture, replay, or export patterns; ScriptoriumAI can borrow explainer-rendering or support-tooling patterns where appropriate.","Moderate uncertainty remains around operational deployment and commercial/license posture; confirm before direct use.","Backfilled from canonized Markdown dossier pass on 2026-04-25.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"HT_timer_training","HyperTwist Timer Gold Standards","1","cs0x7f/cstimer","Keep cstimer as the gold-standard timer benchmark and behavior reference rather than as a donor shell.","Timer behavior, inspection flow, and mature stats ergonomics benchmark.","cs0x7f/cstimer","Hidden value often lives in timer-state edge cases, inspection handling, rolling stats conventions, and event sequencing details rather than in the visible shell.","Minimal transfer outside HyperTwist beyond benchmark behavior and timer semantics.","Low uncertainty: the retained role is benchmark/oracle, not active donor adoption.","Backfilled from canonized Markdown dossier pass on 2026-04-25.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"HT_training_clean_room","HyperTwist Training Clean-Room Bench","6","onionhoney/roux-trainers","Keep the no-license and GPL-heavy training benchmarks in Model A or restrictive custody, using them only for clean-room specs, planner behavior, pedagogy patterns, and narrow donor extraction where already approved.","Clean-room training benchmarks and restrictive training donors beneath the main training stack.","alinen/cube | ambisinister/blindsolve | AviKaufman/Rubix-cube-trainer | MathewKJ2048/Rubiks-cube-simulator | vwcwong/CubeSim","Hidden value often lives in step planners, drill pacing, pedagogical scaffolds, state-history handling, blindfold memo flows, and method-specific trainer logic rather than in the surrounding shell.","Mostly HyperTwist-local, with occasional pedagogy or explainer-transfer value into ScriptoriumAI.","Moderate uncertainty remains around which restrictive training repos are worth future Model A expansion versus remaining benchmark-only.","Backfilled from canonized Markdown dossier pass on 2026-04-25.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"HT_training_stack","HyperTwist Training Stack","7","tao-yu/Alg-Trainer | poliva/cubedex | Lykos/cube_trainer","Start with top core candidates, then merge donor modules in descending queue order, keeping source audit focused on hidden engines rather than UI chrome.","Extract trainer scheduling, timer/replay, case databases, and pedagogy UX.","abunickabhi/5style-Trainer | brownan/Rubiks-Cube-Solver | newyork-anthonyng/rubiks-cross-trainer | Aarav2709/KubeTimr","Hidden value often sits in cube-state representation, scramble generation, weighted drill scheduling, recognition datasets, replay/timer internals, and case database schemas. Hidden value often sits in cube-state representation, scramble generation, weighted drill scheduling, recognition datasets, replay/timer internals, and case database schemas.","project-local first","High uncertainty where the cluster has many metadata-only repos or a large ""unclear"" slice; confirm by source audit before hard demotion.","Original global cluster narratives v3 retained","v6_unified_source_of_truth_pack","v6.3_final_source_of_truth"
|
||||
"MU_misc","HyperTwist Voice / Coaching Stack","4","ggml-org/whisper.cpp | SYSTRAN/faster-whisper | rhasspy/piper | coqui-ai/TTS","Start with ggml-org/whisper.cpp as the bounded native STT anchor and one bounded TTS anchor, then layer hands-free coaching, spoken guidance, and low-latency local voice commands on top.","Bounded voice sidecars for HyperTwist coaching, spoken guidance, and local speech IO.","ggml-org/whisper.cpp | SYSTRAN/faster-whisper | rhasspy/piper | coqui-ai/TTS","Hidden value often lives in streaming segmentation, VAD, device abstraction, latency mitigation, translation chains, local/offline fallback, and coach-friendly command routing.","HyperTwist first","High uncertainty where the cluster has many metadata-only repos or a large ""unclear"" slice; confirm by source audit before hard demotion.","Original global cluster narratives v3 retained","v6_unified_source_of_truth_pack","v6.3_final_source_of_truth"
|
||||
|
|
|
@ -0,0 +1,38 @@
|
|||
# Portfolio Consolidation & Coding-Model Init Prompt (v6.3)
|
||||
|
||||
This document supersedes earlier v6.1/v6.2 init prompts.
|
||||
|
||||
## Canonical Inputs
|
||||
- AGENTS.MD
|
||||
- ARCHITECTURE.MD
|
||||
- API.MD
|
||||
- DEVELOPMENT.MD
|
||||
- PRD.MD
|
||||
- LICENSETRACKING.MD
|
||||
- ROADMAP.MD
|
||||
- SKILLS.MD
|
||||
- v6.3 workbook and CSVs
|
||||
|
||||
## Coding-Model Initialization Prompt
|
||||
|
||||
Treat this session as a source-audit or implementation session against the canonical v6.3 portfolio.
|
||||
|
||||
Rules:
|
||||
- Licensing is not an exclusion filter.
|
||||
- Strong copyleft may be used as-is, as bounded sidecar, clean-room reimplemented, or mined for patterns.
|
||||
- Preserve project-specific design language.
|
||||
- ScriptoriumAI current implemented runtime outranks speculative candidate thinking.
|
||||
- Do not overwrite canonical ranking without evidence-backed deltas.
|
||||
|
||||
Read in order:
|
||||
1. AGENTS.MD
|
||||
2. ARCHITECTURE.MD
|
||||
3. PRD.MD
|
||||
4. ROADMAP.MD
|
||||
5. API.MD
|
||||
6. LICENSETRACKING.MD
|
||||
7. SKILLS.MD
|
||||
8. workbook sheets 00_START_HERE, 01_AUTHORITY_ORDER, 02_MODEL_BOOTSTRAP
|
||||
9. relevant repo row(s)
|
||||
|
||||
Return deltas, not blanket rewrites.
|
||||
|
|
@ -0,0 +1,76 @@
|
|||
"repo","primary_url","best_fit_project_v2","phase_g_bucket","portfolio_role_v3","recommended_action_v2","repurposing_potential_v2","v6_license_annotation","v6_license_annotation_status","v6_license_annotation_source","copyleft_relevance_v6_1","copyleft_strategy_v6_1","copyleft_rationale_v6_1","copyleft_strategy_confidence_v6_1","copyleft_manual_review_trigger_v6_1","v6_3_source_of_truth"
|
||||
"HactarCE/Hyperspeedcube","https://github.com/HactarCE/Hyperspeedcube","HyperTwist","","locked core candidate","integrate","direct","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","high","strategic-or-implemented-component","v6.3_final_source_of_truth"
|
||||
"SYSTRAN/faster-whisper","https://github.com/SYSTRAN/faster-whisper","multi-project","","donor bench","repurpose","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded Python STT donor/service candidate; review chosen model checkpoints separately, but no clean-room path is required by default.","high","model-artifact-review-required","v6.3_final_source_of_truth"
|
||||
"cubing/alg.js","https://github.com/cubing/alg.js","HyperTwist","Donor Bench","donor bench","repurpose","architecture only","GPL-3.0-or-later","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The repo is GPL-3.0-or-later and should remain a focused clean-room donor lane rather than direct donor code. Preserve the parser/AST/traversal semantics through a scrubbed Model A handoff only.","high","gpl-clean-room-donor","v6.3_final_source_of_truth"
|
||||
"cubing/twisty.js","https://github.com/cubing/twisty.js","HyperTwist","Donor Bench","donor bench","repurpose","architecture only","GPL-3.0-or-later","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The repo is GPL-3.0-or-later and should remain a focused clean-room donor lane rather than direct donor code. Preserve viewer/player shell, scrubber, and twisty-element behavior through a scrubbed Model A handoff only.","high","gpl-clean-room-donor","v6.3_final_source_of_truth"
|
||||
"HactarCE/2x2x2x2-Scrambler","https://github.com/HactarCE/2x2x2x2-Scrambler","HyperTwist","Donor Bench","donor bench","repurpose","architecture only","GPL-3.0","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The repo is GPL-3.0 and the source explicitly notes a ported lineage from an earlier scrambler. Retain it only as a focused clean-room donor target and implement any valuable behavior through a scrubbed first-party specification.","high","gpl-clean-room-donor","v6.3_final_source_of_truth"
|
||||
"kkoomen/qbr","https://github.com/kkoomen/qbr","HyperTwist","","locked core candidate","integrate","direct","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","high","strategic-or-implemented-component","v6.3_final_source_of_truth"
|
||||
"coqui-ai/TTS","https://github.com/coqui-ai/TTS","multi-project","","donor bench","repurpose","moderate modification","MPL-2.0 code; mixed model payload licenses","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","bounded_sidecar_or_selective_reimplementation","Code is usable under MPL-2.0, but selected model weights carry mixed per-model licenses and some require separate terms. Keep the repo behind a bounded voice-service seam and decide model adoption case by case rather than treating it as a blanket permissive dependency.","medium","model-license-selection-required","v6.3_final_source_of_truth"
|
||||
"vivaansinghvi07/rubix-cube-solver","https://github.com/vivaansinghvi07/rubix-cube-solver","HyperTwist","Locked Parallel Foundation","locked core candidate","integrate","direct","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","high","strategic-or-implemented-component","v6.3_final_source_of_truth"
|
||||
"ggml-org/whisper.cpp","https://github.com/ggml-org/whisper.cpp","multi-project","","donor bench","repurpose","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. This repo is best used as a bounded offline STT sidecar or native speech-input seam; no clean-room path is required by default.","high","model-artifact-review-recommended","v6.3_final_source_of_truth"
|
||||
"tao-yu/Alg-Trainer","https://github.com/tao-yu/Alg-Trainer","HyperTwist","","locked core candidate","integrate","direct","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","high","strategic-or-implemented-component","v6.3_final_source_of_truth"
|
||||
"rhasspy/piper","https://github.com/rhasspy/piper","multi-project","","donor bench","repurpose","moderate modification","MIT code; voice artifacts reviewed separately","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. The real review point is selected voice artifacts, not the runtime code; keep voice selection separate from code adoption.","high","voice-artifact-review-required","v6.3_final_source_of_truth"
|
||||
"cubing/cubing.js","https://github.com/cubing/cubing.js","HyperTwist","Locked Strategic Donor","locked strategic donor","integrate","direct","MPL-2.0 OR GPL-3.0-or-later","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","bounded_sidecar_or_selective_reimplementation","The repo is dual-licensed MPL-2.0 OR GPL-3.0-or-later. HyperTwist can consume it as a package or bounded adapter under the MPL side, but should avoid a carefree deep private source fork of upstream files.","high","dual-license-boundary-review","v6.3_final_source_of_truth"
|
||||
"cahidenes/rubiks-cube-solver","https://github.com/cahidenes/rubiks-cube-solver","HyperTwist","Locked Strategic Donor","locked strategic donor","integrate","direct","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","high","strategic-or-implemented-component","v6.3_final_source_of_truth"
|
||||
"tentone/rubix-solver","https://github.com/tentone/rubix-solver","HyperTwist","Locked Strategic Donor","locked strategic donor","integrate","direct","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","high","strategic-or-implemented-component","v6.3_final_source_of_truth"
|
||||
"Lykos/cube_trainer","https://github.com/Lykos/cube_trainer","HyperTwist","Locked Strategic Donor","locked strategic donor","integrate","direct","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","high","strategic-or-implemented-component","v6.3_final_source_of_truth"
|
||||
"poliva/cubedex","https://github.com/poliva/cubedex","HyperTwist","Locked Strategic Donor","locked strategic donor","integrate","direct","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","high","strategic-or-implemented-component","v6.3_final_source_of_truth"
|
||||
"kash/cubedesk","https://github.com/kash/cubedesk","HyperTwist","Locked Strategic Donor","locked strategic donor","repurpose","architecture only","GPLv3-or-later in README/LICENSE; package.json says All Rights Reserved","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The repo has conflicting license signals and should remain in restrictive clean-room custody. Treat it as a strategic product-pattern and subsystem extraction target, not as direct donor code.","high","license-contradiction-clean-room-donor","v6.3_final_source_of_truth"
|
||||
"cutelyaware/magiccube4d","https://github.com/cutelyaware/magiccube4d/tree/master","HyperTwist","Locked Strategic Donor","locked strategic donor","repurpose","moderate modification","Custom broad-use license with attribution requested","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","direct_incorporation_ok","The repo is operationally usable because the custom license explicitly allows use, modification, and redistribution, but attribution and provenance obligations must be preserved and tracked.","medium","custom-license-attribution-review","v6.3_final_source_of_truth"
|
||||
"roice3/Magic120Cell","https://github.com/roice3/Magic120Cell","HyperTwist","Locked Strategic Donor","locked strategic donor","repurpose","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The repo is MIT and should remain a specialized 4D interaction donor. Direct donor use is legally straightforward if HyperTwist wants to preserve its dedicated UX and puzzle-handling surfaces.","high","permissive-specialized-donor","v6.3_final_source_of_truth"
|
||||
"roice3/MagicCube5D","https://github.com/roice3/MagicCube5D","HyperTwist","Locked Strategic Donor","locked strategic donor","repurpose","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The repo is MIT and should remain a specialized 5D interaction donor. Direct donor use is legally straightforward if HyperTwist wants to preserve its advanced cube-specific UX and macro behavior.","high","permissive-specialized-donor","v6.3_final_source_of_truth"
|
||||
"cs0x7f/cstimer","https://github.com/cs0x7f/cstimer","HyperTwist","Reserve Bench","Reserve Bench","future candidate","architecture only","GPL-3.0","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","pattern_only_preferred","The repo is GPL timer/training software and the current HyperTwist posture is benchmark-only. Use it to define behavioral expectations and acceptance criteria, not for direct code incorporation.","high","gpl-timer-benchmark","v6.3_final_source_of_truth"
|
||||
"aMonteSl/CodeXR","https://github.com/aMonteSl/CodeXR","HyperTwist","Reserve Bench","Reserve Bench","future candidate","architecture only","GPL-3.0-only","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","pattern_only_preferred","The repo is GPL-3.0-only and, per the dossier-backed HyperTwist posture, is retained only as a reference benchmark. Study interaction patterns and behavior; do not plan direct code incorporation.","high","gpl-reference-only-benchmark","v6.3_final_source_of_truth"
|
||||
"brianpeiris/RiftSketch","https://github.com/brianpeiris/RiftSketch","HyperTwist","Reserve Bench","Reserve Bench","future candidate","architecture only","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","high","strategic-or-implemented-component","v6.3_final_source_of_truth"
|
||||
"abunickabhi/5style-Trainer","https://github.com/abunickabhi/5style-Trainer","HyperTwist","Donor Bench","donor bench","repurpose","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","high","strategic-or-implemented-component","v6.3_final_source_of_truth"
|
||||
"MathewKJ2048/Rubiks-cube-simulator","https://github.com/MathewKJ2048/Rubiks-cube-simulator","HyperTwist","Reserve Bench","Reserve Bench","future candidate","architecture only","GPL-3.0","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The repo is GPL simulator code. Retain it only as clean-room benchmark material and implement any strategically necessary simulator behavior from a scrubbed first-party specification.","high","gpl-clean-room-benchmark","v6.3_final_source_of_truth"
|
||||
"NuiLab/code-vr","https://github.com/NuiLab/code-vr","HyperTwist","Donor Bench","donor bench","repurpose","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The repo is MIT and direct use is legally straightforward, but the current HyperTwist posture is still below-core donor use because the strongest value is in XR pedagogy, embodied onboarding, and code-to-scene boundary ideas rather than product-core ownership.","high","below-core-mit-donor","v6.3_final_source_of_truth"
|
||||
"ShellPuppy/RCube","https://github.com/ShellPuppy/RCube","HyperTwist","Reserve Bench","Reserve Bench","future candidate","architecture only","GPL-3.0","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","pattern_only_preferred","The repo is GPL large-N solver code and is retained only as an algorithm/reference benchmark. Use it for comparison and expectations, not direct source incorporation.","high","gpl-large-n-benchmark","v6.3_final_source_of_truth"
|
||||
"brownan/Rubiks-Cube-Solver","https://github.com/brownan/Rubiks-Cube-Solver","HyperTwist","Reserve Bench","Reserve Bench","future candidate","architecture only","GPL-3.0","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The repo is GPL-3.0 and should remain a benchmark oracle plus clean-room optimal-solver candidate. Preserve correctness/oracle behavior and produce any first-party solver through a scrubbed clean-room process.","high","gpl-oracle-clean-room-review","v6.3_final_source_of_truth"
|
||||
"newyork-anthonyng/rubiks-cross-trainer","https://github.com/newyork-anthonyng/rubiks-cross-trainer","HyperTwist","Donor Bench","donor bench","repurpose","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","high","strategic-or-implemented-component","v6.3_final_source_of_truth"
|
||||
"vwcwong/CubeSim","https://github.com/vwcwong/CubeSim","HyperTwist","Reserve Bench","Reserve Bench","future candidate","architecture only","GPL-3.0","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The repo is GPL simulator code. Retain it only as clean-room benchmark material and implement any strategically necessary state/history behavior from a scrubbed first-party specification.","high","gpl-clean-room-benchmark","v6.3_final_source_of_truth"
|
||||
"AviKaufman/Rubix-cube-trainer","https://github.com/AviKaufman/Rubix-cube-trainer","HyperTwist","Reserve Bench","Reserve Bench","future candidate","architecture only","All Rights Reserved","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The repo is all-rights-reserved. Retain it only as clean-room benchmark material and implement any strategically necessary tutorial behavior from a scrubbed first-party specification.","high","all-rights-reserved-clean-room-benchmark","v6.3_final_source_of_truth"
|
||||
"alinen/cube","https://github.com/alinen/cube","HyperTwist","Reserve Bench","Reserve Bench","future candidate","architecture only","no explicit license visible","pending_repo_license_audit","not_resolved_from_uploaded_materials","license_unknown_pending","reverse_engineer_preferred","No explicit permissive license is visible. Retain this repo only as clean-room benchmark material and implement any strategically necessary behavior from a scrubbed first-party specification.","medium","no-license-clean-room-benchmark","v6.3_final_source_of_truth"
|
||||
"ambisinister/blindsolve","https://github.com/ambisinister/blindsolve","HyperTwist","Reserve Bench","Reserve Bench","future candidate","architecture only","no explicit license visible","pending_repo_license_audit","not_resolved_from_uploaded_materials","license_unknown_pending","reverse_engineer_preferred","No explicit permissive license is visible. Retain this repo only as clean-room benchmark material and implement any strategically necessary memo-practice behavior from a scrubbed first-party specification.","medium","no-license-clean-room-benchmark","v6.3_final_source_of_truth"
|
||||
"efrantar/rob-twophase","https://github.com/efrantar/rob-twophase","HyperTwist","Reserve Bench","Reserve Bench","future candidate","architecture only","GPL-3.0","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","pattern_only_preferred","The repo is GPL solver/oracle code and the current HyperTwist posture is benchmark-only. Use it for correctness, metric, and performance comparison rather than direct source incorporation.","high","gpl-solver-oracle-benchmark","v6.3_final_source_of_truth"
|
||||
"onionhoney/roux-trainers","https://github.com/onionhoney/roux-trainers","HyperTwist","Donor Bench","donor bench","repurpose","architecture only","GPL-3.0","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The repo is GPLv3 and should not be used as direct donor code in the HyperTwist core. Its value is in selective behavior and subsystem extraction through a clean-room Model A / Model B process.","high","gpl-clean-room-donor","v6.3_final_source_of_truth"
|
||||
"yakupbilen/drl-rubiks-cube","https://github.com/yakupbilen/drl-rubiks-cube","HyperTwist","Reserve Bench","Reserve Bench","future candidate","architecture only","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","high","strategic-or-implemented-component","v6.3_final_source_of_truth"
|
||||
"Hypercubers/hypercubing.xyz","https://github.com/Hypercubers/hypercubing.xyz","HyperTwist","Locked Strategic Donor","locked strategic donor","repurpose","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The repo is MIT and is retained as a high-value knowledge and curriculum donor. Direct use of code/content structures is legally straightforward where it materially helps HyperTwist.","high","permissive-knowledge-donor","v6.3_final_source_of_truth"
|
||||
"Aarav2709/KubeTimr","https://github.com/Aarav2709/KubeTimr","HyperTwist","Donor Bench","donor bench","repurpose","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is permissively licensed and currently best treated as a focused subsystem donor for timer-state logic, split-phase handling, local persistence, and keyboard-first practice flow. Selective incorporation is legally straightforward, but the product shell should still be reshaped to fit HyperTwist.","high","routine-review-only","v6.3_final_source_of_truth"
|
||||
"roice3/MagicTile","https://github.com/roice3/MagicTile","HyperTwist","Locked Strategic Donor","locked strategic donor","repurpose","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The repo is MIT and is explicitly retained as a top-tier geometry/topology donor. Direct donor use is legally straightforward if the architecture benefits from it.","high","permissive-top-tier-donor","v6.3_final_source_of_truth"
|
||||
"PostHog/posthog","https://github.com/PostHog/posthog","HyperTwist","","donor bench","repurpose","moderate modification","MIT outside ee/; enterprise-restricted in ee/","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","bounded_sidecar_or_selective_reimplementation","The repo is mixed-license: MIT outside ee/ and enterprise-restricted inside ee/. Use only clearly MIT paths as bounded telemetry, replay, and feature-governance donor material, and exclude or reimplement enterprise-gated paths.","high","mixed-license-path-review-required","v6.3_final_source_of_truth"
|
||||
"met4citizen/TalkingHead","https://github.com/met4citizen/TalkingHead","HyperTwist","Donor Bench","donor bench","repurpose","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser-side donor for embodied coach presentation rather than as a product shell.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"apache/echarts","https://github.com/apache/echarts","HyperTwist","Donor Bench","donor bench","repurpose","moderate modification","Apache-2.0","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is Apache-2.0 and direct use is allowed. Treat it as a bounded reporting and analytics donor.","high","notice-file-review","v6.3_markdown_backfill"
|
||||
"ecomfe/echarts-gl","https://github.com/ecomfe/echarts-gl","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","BSD-3-Clause","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is BSD-3-Clause and direct use is allowed. Treat it as a bounded 3D analytics extension rather than a runtime foundation.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"KhronosGroup/glTF-Sample-Viewer","https://github.com/KhronosGroup/glTF-Sample-Viewer","HyperTwist","Donor Bench","donor bench","repurpose","moderate modification","Apache-2.0","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is Apache-2.0 and direct use is allowed. Treat it as a bounded standards-viewer and asset-QA donor.","high","notice-file-review","v6.3_markdown_backfill"
|
||||
"google/model-viewer","https://github.com/google/model-viewer","HyperTwist","Donor Bench","donor bench","repurpose","moderate modification","Apache-2.0","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is Apache-2.0 and direct use is allowed. Treat it as a bounded browser presentation and inspection donor.","high","notice-file-review","v6.3_markdown_backfill"
|
||||
"mrdoob/three.js","https://github.com/mrdoob/three.js","HyperTwist","Donor Bench","donor bench","repurpose","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser 3D substrate rather than as an owned runtime foundation.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"pmndrs/postprocessing","https://github.com/pmndrs/postprocessing","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","Zlib","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is Zlib and direct use is allowed. Treat it as a bounded browser post-processing dependency.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"pmndrs/react-three-fiber","https://github.com/pmndrs/react-three-fiber","HyperTwist","Donor Bench","donor bench","repurpose","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser React renderer substrate.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"pmndrs/drei","https://github.com/pmndrs/drei","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser helper layer above react-three-fiber.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"pmndrs/xr","https://github.com/pmndrs/xr","HyperTwist","Donor Bench","donor bench","repurpose","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser XR interaction donor.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"pmndrs/uikit","https://github.com/pmndrs/uikit","HyperTwist","Donor Bench","donor bench","repurpose","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser spatial UI donor.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"pmndrs/react-spring","https://github.com/pmndrs/react-spring","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser motion substrate.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"screenpipe/screenpipe","https://github.com/screenpipe/screenpipe","HyperTwist","Donor Bench","donor bench","repurpose","moderate modification","MIT OR Apache-2.0 core; enterprise-restricted ee/","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","bounded_sidecar_or_selective_reimplementation","The repo is permissive in its core paths but includes enterprise-restricted ee/ content. Use only clearly permissive core paths as bounded capture/history/replay donor material and exclude or reimplement enterprise-gated paths.","high","mixed-license-path-review-required","v6.3_markdown_backfill"
|
||||
"remotion-dev/remotion","https://github.com/remotion-dev/remotion","HyperTwist","Donor Bench","donor bench","repurpose","moderate modification","Custom two-tier commercial license","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","bounded_sidecar_or_selective_reimplementation","The repo uses a custom two-tier commercial license and should remain a bounded media-export and explainer sidecar. Review the commercial terms before direct use and do not treat it as a carefree donor.","high","commercial-license-sidecar-review","v6.3_markdown_backfill"
|
||||
"ecomfe/zrender","https://github.com/ecomfe/zrender","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","BSD-3-Clause","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is BSD-3-Clause and direct use is allowed. Treat it as a bounded 2D render substrate beneath the reporting stack.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"pissang/claygl","https://github.com/pissang/claygl","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","BSD-style permissive (see LICENSE)","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The repo carries a BSD-style permissive license in its LICENSE file and direct use is viable. Treat it as a bounded WebGL substrate rather than a product lane.","medium","license-text-normalization-review","v6.3_markdown_backfill"
|
||||
"pissang/clay-viewer","https://github.com/pissang/clay-viewer","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","BSD-3-Clause","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is BSD-3-Clause and direct use is allowed. Treat it as a bounded browser viewer/editor sidecar.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"KhronosGroup/glTF-Sample-Renderer","https://github.com/KhronosGroup/glTF-Sample-Renderer","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","Apache-2.0","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is Apache-2.0 and direct use is allowed. Treat it as a bounded renderer substrate beneath asset viewers.","high","notice-file-review","v6.3_markdown_backfill"
|
||||
"google/model-viewer/packages/space-opera","https://github.com/google/model-viewer/tree/main/packages/space-opera","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","Apache-2.0","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is Apache-2.0 and direct use is allowed. Treat it as a bounded browser editor and inspection donor beneath model-viewer.","high","notice-file-review","v6.3_markdown_backfill"
|
||||
"google/model-viewer/packages/render-fidelity-tools","https://github.com/google/model-viewer/tree/main/packages/render-fidelity-tools","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","Apache-2.0","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is Apache-2.0 and direct use is allowed. Treat it as a bounded QA and fidelity-testing donor.","high","notice-file-review","v6.3_markdown_backfill"
|
||||
"google/model-viewer/packages/model-viewer-effects","https://github.com/google/model-viewer/tree/main/packages/model-viewer-effects","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","Apache-2.0","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is Apache-2.0 and direct use is allowed. Treat it as a bounded browser emphasis and effect donor beneath model-viewer.","high","notice-file-review","v6.3_markdown_backfill"
|
||||
"google/model-viewer/packages/modelviewer.dev","https://github.com/google/model-viewer/tree/main/packages/modelviewer.dev","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","Apache-2.0","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is Apache-2.0 and direct use is allowed. Treat it as a bounded docs and demo donor.","high","notice-file-review","v6.3_markdown_backfill"
|
||||
"google/model-viewer/packages/shared-assets","https://github.com/google/model-viewer/tree/main/packages/shared-assets","HyperTwist","Donor Bench","donor bench","repurpose","architecture only","Apache-2.0 container; mixed per-asset terms","known_from_reference_material","uploaded_reference_docs","mixed_or_boundary_sensitive_known","bounded_sidecar_or_selective_reimplementation","The package container is Apache-2.0, but the actual payloads carry mixed per-asset terms. Treat it as a whitelisted fixture pack, not a blanket shippable asset source.","high","mixed-asset-whitelist-review","v6.3_markdown_backfill"
|
||||
"pmndrs/react-postprocessing","https://github.com/pmndrs/react-postprocessing","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded React wrapper layer above browser post-processing.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"pmndrs/three-stdlib","https://github.com/pmndrs/three-stdlib","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded utility substrate beneath three.js-adjacent browser lanes.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"pmndrs/maath","https://github.com/pmndrs/maath","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded math-helper substrate.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"pmndrs/zustand","https://github.com/pmndrs/zustand","HyperTwist","Donor Bench","donor bench","repurpose","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser state-management substrate.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"pmndrs/leva","https://github.com/pmndrs/leva","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser parameter-UI donor.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"pmndrs/use-gesture","https://github.com/pmndrs/use-gesture","HyperTwist","Donor Bench","donor bench","repurpose","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser gesture and pointer-input substrate.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"@react-spring/parallax","https://github.com/pmndrs/react-spring/tree/main/packages/parallax","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded layered-motion and explainer sidecar.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"@react-spring/rafz","https://github.com/pmndrs/react-spring/tree/main/packages/rafz","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser scheduling utility.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"@react-spring/animated","https://github.com/pmndrs/react-spring/tree/main/packages/animated","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded animatable-component substrate.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"@react-spring/core","https://github.com/pmndrs/react-spring/tree/main/packages/core","HyperTwist","Donor Bench","donor bench","repurpose","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded spring-runtime core beneath higher-level motion layers.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"@react-spring/shared","https://github.com/pmndrs/react-spring/tree/main/packages/shared","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded motion utility substrate.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
"@react-spring/types","https://github.com/pmndrs/react-spring/tree/main/packages/types","HyperTwist","Merge Bench","merge bench","integrate","moderate modification","MIT","known_from_reference_material","uploaded_reference_docs","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded type-contract substrate.","high","standard-notice-review","v6.3_markdown_backfill"
|
||||
|
41
docs/repo_portfolio_unified_merger_matrix_v6_3.csv
Normal file
41
docs/repo_portfolio_unified_merger_matrix_v6_3.csv
Normal file
|
|
@ -0,0 +1,41 @@
|
|||
"repo","repo_key","partner_repo","merge_type","merge_rationale","scriptorium_bucket","source_audit_priority","_repo_norm","source_of_truth","best_fit_project","taxonomy_hardened","portfolio_role_v3","execution_queue_order","merge_rank","realization_hint","v6_source_of_truth","v6_3_source_of_truth"
|
||||
"HactarCE/Hyperspeedcube","","cubing/cubing.js","3D engine + notation/state donor","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","","","","Original global merger matrix v3 retained","HyperTwist","hypercubing / nD engine","locked core candidate","1.0","1.0","Map module boundaries; Identify hidden reusable internals; Define adapter/API boundary to target anchors; Write extraction tests against upstream behavior; Isolate puzzle/state core; Extract render/input abstractions; Document notation and save format","v6_unified_source_of_truth_pack","v6.3_final_source_of_truth"
|
||||
"HactarCE/Hyperspeedcube","","tao-yu/Alg-Trainer","training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","","","","Original global merger matrix v3 retained","HyperTwist","hypercubing / nD engine","locked core candidate","1.0","2.0","Map module boundaries; Identify hidden reusable internals; Define adapter/API boundary to target anchors; Write extraction tests against upstream behavior; Isolate puzzle/state core; Extract render/input abstractions; Document notation and save format","v6_unified_source_of_truth_pack","v6.3_final_source_of_truth"
|
||||
"HactarCE/Hyperspeedcube","","cross-project transfer candidate","future merger","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","","","","Original global merger matrix v3 retained","HyperTwist","hypercubing / nD engine","locked core candidate","1.0","3.0","Map module boundaries; Identify hidden reusable internals; Define adapter/API boundary to target anchors; Write extraction tests against upstream behavior; Isolate puzzle/state core; Extract render/input abstractions; Document notation and save format","v6_unified_source_of_truth_pack","v6.3_final_source_of_truth"
|
||||
"kkoomen/qbr","","vivaansinghvi07/rubix-cube-solver","perception + replay donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","","","","Original global merger matrix v3 retained","HyperTwist","vision / perception / AR","locked core candidate","2.0","1.0","Map module boundaries; Identify hidden reusable internals; Define adapter/API boundary to target anchors; Write extraction tests against upstream behavior; Benchmark calibration pipeline; Extract state reconstruction; Wrap with camera/AR adapter","v6_unified_source_of_truth_pack","v6.3_final_source_of_truth"
|
||||
"kkoomen/qbr","","cubing/cubing.js","state/render backend","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","","","","Original global merger matrix v3 retained","HyperTwist","vision / perception / AR","locked core candidate","2.0","2.0","Map module boundaries; Identify hidden reusable internals; Define adapter/API boundary to target anchors; Write extraction tests against upstream behavior; Benchmark calibration pipeline; Extract state reconstruction; Wrap with camera/AR adapter","v6_unified_source_of_truth_pack","v6.3_final_source_of_truth"
|
||||
"vivaansinghvi07/rubix-cube-solver","","kkoomen/qbr","foundation + perception donor","Use this repo against the partner as an augmenting layer; preserve the partner as the likely base and mine this repo for capabilities that improve breadth, UX, or specialization.","","","","Original global merger matrix v3 retained","HyperTwist","vision / perception / AR","locked core candidate","3.0","1.0","Map module boundaries; Identify hidden reusable internals; Define adapter/API boundary to target anchors; Write extraction tests against upstream behavior; Benchmark calibration pipeline; Extract state reconstruction; Wrap with camera/AR adapter","v6_unified_source_of_truth_pack","v6.3_final_source_of_truth"
|
||||
"tao-yu/Alg-Trainer","","poliva/cubedex","specialized training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","","","","Original global merger matrix v3 retained","HyperTwist","cubing trainer / solver / timing","locked core candidate","4.0","1.0","Map module boundaries; Identify hidden reusable internals; Define adapter/API boundary to target anchors; Write extraction tests against upstream behavior; Extract cube-state model; Normalize trainer/case schema; Expose analytics and replay hooks","v6_unified_source_of_truth_pack","v6.3_final_source_of_truth"
|
||||
"tao-yu/Alg-Trainer","","Lykos/cube_trainer","sampling/analytics donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","","","","Original global merger matrix v3 retained","HyperTwist","cubing trainer / solver / timing","locked core candidate","4.0","2.0","Map module boundaries; Identify hidden reusable internals; Define adapter/API boundary to target anchors; Write extraction tests against upstream behavior; Extract cube-state model; Normalize trainer/case schema; Expose analytics and replay hooks","v6_unified_source_of_truth_pack","v6.3_final_source_of_truth"
|
||||
"cubing/cubing.js","","project-local anchor","base + donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","","","","Original global merger matrix v3 retained","HyperTwist","interface / visualization / shell surface","locked core candidate","5.0","1.0","Map module boundaries; Identify hidden reusable internals; Define adapter/API boundary to target anchors; Write extraction tests against upstream behavior; Extract layout/scene primitives; Map import/export schema; Detach UI shell from backend assumptions","v6_unified_source_of_truth_pack","v6.3_final_source_of_truth"
|
||||
"cubing/cubing.js","","shared portfolio utility","augmenter","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","","","","Original global merger matrix v3 retained","HyperTwist","interface / visualization / shell surface","locked core candidate","5.0","2.0","Map module boundaries; Identify hidden reusable internals; Define adapter/API boundary to target anchors; Write extraction tests against upstream behavior; Extract layout/scene primitives; Map import/export schema; Detach UI shell from backend assumptions","v6_unified_source_of_truth_pack","v6.3_final_source_of_truth"
|
||||
"Lykos/cube_trainer","","tao-yu/Alg-Trainer","base + donor swarm","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","","","","Original global merger matrix v3 retained","HyperTwist","cubing trainer / solver / timing","candidate core","8.0","1.0","Map module boundaries; Identify hidden reusable internals; Define adapter/API boundary to target anchors; Write extraction tests against upstream behavior; Extract cube-state model; Normalize trainer/case schema; Expose analytics and replay hooks","v6_unified_source_of_truth_pack","v6.3_final_source_of_truth"
|
||||
"kash/cubedesk","","HactarCE/Hyperspeedcube","foundation + donor","Use this repo against the partner as an augmenting layer; preserve the partner as the likely base and mine this repo for capabilities that improve breadth, UX, or specialization.","","","","Original global merger matrix v3 retained","HyperTwist","hypercubing / nD engine","candidate core","9.0","1.0","Map module boundaries; Identify hidden reusable internals; Define adapter/API boundary to target anchors; Write extraction tests against upstream behavior; Isolate puzzle/state core; Extract render/input abstractions; Document notation and save format","v6_unified_source_of_truth_pack","v6.3_final_source_of_truth"
|
||||
"HactarCE/2x2x2x2-Scrambler","hactarce/2x2x2x2-scrambler","HactarCE/Hyperspeedcube","foundation repo + feature donor","Use HactarCE/2x2x2x2-Scrambler as a HyperTwist donor into HactarCE/Hyperspeedcube for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","","P2","hactarce/2x2x2x2-scrambler","v6_unified_source_of_truth_pack","HyperTwist","puzzle_simulation_training_donor","Reserve Bench","","1.0","Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training.","","v6.3_final_source_of_truth"
|
||||
"HactarCE/2x2x2x2-Scrambler","hactarce/2x2x2x2-scrambler","cubing/cubing.js","engine repo + interface donor","Use HactarCE/2x2x2x2-Scrambler as a HyperTwist donor into cubing/cubing.js for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","","P2","hactarce/2x2x2x2-scrambler","v6_unified_source_of_truth_pack","HyperTwist","puzzle_simulation_training_donor","Reserve Bench","","2.0","Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training.","","v6.3_final_source_of_truth"
|
||||
"HactarCE/2x2x2x2-Scrambler","hactarce/2x2x2x2-scrambler","kkoomen/qbr","feature extraction only","Use HactarCE/2x2x2x2-Scrambler as a HyperTwist donor into kkoomen/qbr for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","","P2","hactarce/2x2x2x2-scrambler","v6_unified_source_of_truth_pack","HyperTwist","puzzle_simulation_training_donor","Reserve Bench","","3.0","Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training.","","v6.3_final_source_of_truth"
|
||||
"HactarCE/hyperspeedcube","hactarce/hyperspeedcube","HactarCE/Hyperspeedcube","foundation repo + feature donor","Use HactarCE/hyperspeedcube as a HyperTwist donor into HactarCE/Hyperspeedcube for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","","P0","hactarce/hyperspeedcube","v6_unified_source_of_truth_pack","HyperTwist","puzzle_simulation_training_donor","Donor Bench","","1.0","Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training.","","v6.3_final_source_of_truth"
|
||||
"HactarCE/hyperspeedcube","hactarce/hyperspeedcube","cubing/cubing.js","engine repo + interface donor","Use HactarCE/hyperspeedcube as a HyperTwist donor into cubing/cubing.js for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","","P0","hactarce/hyperspeedcube","v6_unified_source_of_truth_pack","HyperTwist","puzzle_simulation_training_donor","Donor Bench","","2.0","Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training.","","v6.3_final_source_of_truth"
|
||||
"HactarCE/hyperspeedcube","hactarce/hyperspeedcube","kkoomen/qbr","feature extraction only","Use HactarCE/hyperspeedcube as a HyperTwist donor into kkoomen/qbr for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","","P0","hactarce/hyperspeedcube","v6_unified_source_of_truth_pack","HyperTwist","puzzle_simulation_training_donor","Donor Bench","","3.0","Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training.","","v6.3_final_source_of_truth"
|
||||
"cubing/alg.js","cubing/alg.js","HactarCE/Hyperspeedcube","foundation repo + feature donor","Use cubing/alg.js as a HyperTwist donor into HactarCE/Hyperspeedcube for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","","P0","cubing/alg.js","v6_unified_source_of_truth_pack","HyperTwist","puzzle_simulation_training_donor","Donor Bench","","1.0","Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training.","","v6.3_final_source_of_truth"
|
||||
"cubing/alg.js","cubing/alg.js","cubing/cubing.js","engine repo + interface donor","Use cubing/alg.js as a HyperTwist donor into cubing/cubing.js for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","","P0","cubing/alg.js","v6_unified_source_of_truth_pack","HyperTwist","puzzle_simulation_training_donor","Donor Bench","","2.0","Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training.","","v6.3_final_source_of_truth"
|
||||
"cubing/alg.js","cubing/alg.js","kkoomen/qbr","feature extraction only","Use cubing/alg.js as a HyperTwist donor into kkoomen/qbr for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","","P0","cubing/alg.js","v6_unified_source_of_truth_pack","HyperTwist","puzzle_simulation_training_donor","Donor Bench","","3.0","Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training.","","v6.3_final_source_of_truth"
|
||||
"cubing/cubing.js","cubing/cubing.js","HactarCE/Hyperspeedcube","foundation repo + feature donor","Use cubing/cubing.js as a HyperTwist donor into HactarCE/Hyperspeedcube for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","","P0","cubing/cubing.js","v6_unified_source_of_truth_pack","HyperTwist","puzzle_simulation_training_donor","Donor Bench","","1.0","Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training.","","v6.3_final_source_of_truth"
|
||||
"cubing/cubing.js","cubing/cubing.js","cubing/cubing.js","engine repo + interface donor","Use cubing/cubing.js as a HyperTwist donor into cubing/cubing.js for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","","P0","cubing/cubing.js","v6_unified_source_of_truth_pack","HyperTwist","puzzle_simulation_training_donor","Donor Bench","","2.0","Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training.","","v6.3_final_source_of_truth"
|
||||
"cubing/cubing.js","cubing/cubing.js","kkoomen/qbr","feature extraction only","Use cubing/cubing.js as a HyperTwist donor into kkoomen/qbr for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","","P0","cubing/cubing.js","v6_unified_source_of_truth_pack","HyperTwist","puzzle_simulation_training_donor","Donor Bench","","3.0","Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training.","","v6.3_final_source_of_truth"
|
||||
"cubing/twisty.js","cubing/twisty.js","HactarCE/Hyperspeedcube","foundation repo + feature donor","Use cubing/twisty.js as a HyperTwist donor into HactarCE/Hyperspeedcube for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","","P0","cubing/twisty.js","v6_unified_source_of_truth_pack","HyperTwist","puzzle_simulation_training_donor","Donor Bench","","1.0","Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training.","","v6.3_final_source_of_truth"
|
||||
"cubing/twisty.js","cubing/twisty.js","cubing/cubing.js","engine repo + interface donor","Use cubing/twisty.js as a HyperTwist donor into cubing/cubing.js for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","","P0","cubing/twisty.js","v6_unified_source_of_truth_pack","HyperTwist","puzzle_simulation_training_donor","Donor Bench","","2.0","Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training.","","v6.3_final_source_of_truth"
|
||||
"cubing/twisty.js","cubing/twisty.js","kkoomen/qbr","feature extraction only","Use cubing/twisty.js as a HyperTwist donor into kkoomen/qbr for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","","P0","cubing/twisty.js","v6_unified_source_of_truth_pack","HyperTwist","puzzle_simulation_training_donor","Donor Bench","","3.0","Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training.","","v6.3_final_source_of_truth"
|
||||
"apache/echarts","apache/echarts","ecomfe/echarts-gl","3D analytics extension","Use the partner as a bounded 3D analytics and explainer layer above the main reporting surface, while preserving echarts as the primary browser analytics shell.","Donor Bench","P2","apache/echarts","Backfilled from canonized Markdown dossier pass on 2026-04-25.","HyperTwist","analytics / visualization / reporting","donor bench","","1.0","Map chart/runtime boundaries; keep echarts as the reporting base; attach echarts-gl only where 3D explanatory views materially improve analytics.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"apache/echarts","apache/echarts","ecomfe/zrender","2D render substrate","Use the partner as the lower-level 2D render and event substrate when HyperTwist needs control beneath echarts for custom overlays, widgets, or minimaps.","Donor Bench","P2","apache/echarts","Backfilled from canonized Markdown dossier pass on 2026-04-25.","HyperTwist","analytics / visualization / reporting","donor bench","","2.0","Keep zrender beneath echarts; only drop lower when custom overlays or lower-level interaction surfaces justify the added complexity.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"google/model-viewer","google/model-viewer","KhronosGroup/glTF-Sample-Viewer","presentation + standards viewer","Pair model-viewer as the productized browser presentation shell with the partner as the standards-aware validation and QA counterpart.","Donor Bench","P2","google/model-viewer","Backfilled from canonized Markdown dossier pass on 2026-04-25.","HyperTwist","interface / visualization / shell surface","donor bench","","1.0","Keep model-viewer as the user-facing browser shell and use the partner selectively for validation, standards checks, and asset QA.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"google/model-viewer","google/model-viewer","mrdoob/three.js","browser 3D substrate","Use the partner as the browser 3D substrate beneath custom model-viewer-adjacent surfaces or deeper browser-side presentation work.","Donor Bench","P2","google/model-viewer","Backfilled from canonized Markdown dossier pass on 2026-04-25.","HyperTwist","interface / visualization / shell surface","donor bench","","2.0","Stay at the model-viewer layer by default; fall through to three.js only when HyperTwist needs lower-level browser scene ownership.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"KhronosGroup/glTF-Sample-Viewer","khronosgroup/gltf-sample-viewer","KhronosGroup/glTF-Sample-Renderer","viewer + renderer substrate","Use the renderer as the standards-aware lower-level substrate beneath the viewer shell for asset QA and preview flows.","Donor Bench","P3","khronosgroup/gltf-sample-viewer","Backfilled from canonized Markdown dossier pass on 2026-04-25.","HyperTwist","interface / visualization / shell surface","donor bench","","1.0","Preserve the viewer shell as the higher-level standards surface and the renderer as the lower-level asset/runtime substrate.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"mrdoob/three.js","mrdoob/three.js","pmndrs/react-three-fiber","renderer + React layer","Use react-three-fiber as the React-side renderer layer above three.js for browser companion surfaces, not as a replacement for the underlying substrate.","Donor Bench","P2","mrdoob/three.js","Backfilled from canonized Markdown dossier pass on 2026-04-25.","HyperTwist","interface / visualization / shell surface","donor bench","","1.0","Treat three.js as the browser 3D substrate and react-three-fiber as the React integration layer above it.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"pmndrs/react-three-fiber","pmndrs/react-three-fiber","pmndrs/xr","renderer + XR interaction layer","Use the partner as the immersive interaction layer above the React renderer substrate for browser XR companion surfaces.","Donor Bench","P2","pmndrs/react-three-fiber","Backfilled from canonized Markdown dossier pass on 2026-04-25.","HyperTwist","interface / visualization / shell surface","donor bench","","1.0","Keep react-three-fiber as the render substrate and layer xr on top only for immersive interaction and session behavior.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"pmndrs/react-three-fiber","pmndrs/react-three-fiber","pmndrs/uikit","renderer + spatial UI layer","Use the partner as the spatial UI layer above the React renderer substrate for immersive dashboards, menus, and coach panels.","Donor Bench","P2","pmndrs/react-three-fiber","Backfilled from canonized Markdown dossier pass on 2026-04-25.","HyperTwist","interface / visualization / shell surface","donor bench","","2.0","Keep react-three-fiber as the scene/render base and layer uikit on top for panel and spatial UI behavior.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"pmndrs/react-spring","pmndrs/react-spring","pmndrs/use-gesture","motion + gesture layer","Use the partner to drive richer input and gesture surfaces that feed the motion and interaction layer built with react-spring.","Merge Bench","P3","pmndrs/react-spring","Backfilled from canonized Markdown dossier pass on 2026-04-25.","HyperTwist","interface / visualization / shell surface","merge bench","","1.0","Keep use-gesture as the input substrate and react-spring as the motion runtime above it.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"met4citizen/TalkingHead","met4citizen/talkinghead","coqui-ai/TTS","embodied coach + voice donor","Use coqui-ai/TTS as the richer voice-output donor behind TalkingHead when HyperTwist needs multilingual or cloning-capable embodied coach narration.","Donor Bench","P2","met4citizen/talkinghead","Backfilled from canonized Markdown dossier pass on 2026-04-25.","HyperTwist","interface / visualization / shell surface","donor bench","","1.0","Keep TalkingHead as the embodied browser surface and bind the richer TTS lane behind a bounded voice-service seam.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"met4citizen/TalkingHead","met4citizen/talkinghead","rhasspy/piper","embodied coach + local voice sidecar","Use rhasspy/piper as the lean local TTS sidecar behind TalkingHead when low-latency offline coach narration is the priority.","Donor Bench","P2","met4citizen/talkinghead","Backfilled from canonized Markdown dossier pass on 2026-04-25.","HyperTwist","interface / visualization / shell surface","donor bench","","2.0","Keep TalkingHead as the embodied browser surface and bind piper behind a bounded local voice seam for offline narration.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"screenpipe/screenpipe","screenpipe/screenpipe","PostHog/posthog","capture/replay + telemetry governance","Use screenpipe for local capture/history/replay and the partner for telemetry, replay governance, and feature-flag control-plane patterns.","Donor Bench","P2","screenpipe/screenpipe","Backfilled from canonized Markdown dossier pass on 2026-04-25.","HyperTwist","capture / replay / support-plane","donor bench","","1.0","Keep screenpipe on the local capture side and PostHog on the telemetry and governance side; do not let either redefine the product shell.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
"remotion-dev/remotion","remotion-dev/remotion","met4citizen/TalkingHead","avatar explainer + media export","Use TalkingHead for embodied coach capture surfaces and the partner for rendered replay explainers or export pipelines.","Donor Bench","P3","remotion-dev/remotion","Backfilled from canonized Markdown dossier pass on 2026-04-25.","HyperTwist","media / rendering / export","donor bench","","1.0","Keep remotion as the bounded export sidecar and TalkingHead as the embodied browser coach surface.","v6_unified_source_of_truth_pack","v6.3_markdown_backfill"
|
||||
|
76
docs/repo_portfolio_unified_operational_v6_3.csv
Normal file
76
docs/repo_portfolio_unified_operational_v6_3.csv
Normal file
File diff suppressed because one or more lines are too long
76
docs/repo_portfolio_unified_phase_g_v6_3.csv
Normal file
76
docs/repo_portfolio_unified_phase_g_v6_3.csv
Normal file
File diff suppressed because one or more lines are too long
1
docs/repo_portfolio_unified_re_layer_matrix_v6_3.csv
Normal file
1
docs/repo_portfolio_unified_re_layer_matrix_v6_3.csv
Normal file
|
|
@ -0,0 +1 @@
|
|||
repo,primary_url,best_fit_project_v2,phase_g_bucket,v6_2_sre_layer,v6_2_sre_stratum,v6_2_sre_role,v6_2_sre_family,v6_2_sre_notes,v6_license_annotation,v6_license_annotation_status,v6_license_annotation_source,copyleft_strategy_v6_1,copyleft_strategy_confidence_v6_1,preferred_boundary_model_v6_1,v6_3_source_of_truth
|
||||
|
312
docs/repo_portfolio_unified_source_audit_v6_3.csv
Normal file
312
docs/repo_portfolio_unified_source_audit_v6_3.csv
Normal file
|
|
@ -0,0 +1,312 @@
|
|||
"repo","primary_url","project","phase_g_bucket","stack_layer","audit_tier","tier_queue_order","global_order","wave_number","portfolio_priority_score","execution_priority_score_v3","current_confidence","modification_scope_detail_v3","recommended_action_v2","repurposing_potential_v2","audit_goal","inspect_emphasis","source_code_audit_targets","source_inspection_questions","integration_realization_detail","consolidation_detail","repurpose_detail","merger_partner_1","merger_type_1","merger_rationale_1","merger_partner_2","merger_type_2","merger_rationale_2","merger_partner_3","merger_type_3","merger_rationale_3","cross_project_transfer_targets","cross_project_transfer_rationale","reclassify_up_if","reclassify_down_if","deliverable_expected","session_note_template","recommended_context_packet","phase_g_master_list_rationale","phase_g_bucket_reason","coding_model_instruction_v3","source_audit_packet_id","cluster_tag","_repo_norm","v5_runtime_project","v5_scriptorium_override_status","v5_scriptorium_bucket","v5_scriptorium_stack_layer","v5_scriptorium_current_reality_status","v5_scriptorium_supersedes_prior_assessment","v5_source_of_truth","v6_license_annotation","v6_license_annotation_status","v6_license_annotation_source","v6_supplemental_intake_present","v6_supplemental_source_groups","v6_supplemental_source_sections","v6_supplemental_source_files","v6_reference_material_position","v6_kali_agent_access_relevance","v6_branch_seed_prompt_included","v6_branch_seed_scope","v6_intake_wave","v6_notes","v6_source_of_truth","project_rank_num","tier_rank_num","priority_num","copyleft_relevance_v6_1","copyleft_strategy_v6_1","copyleft_rationale_v6_1","preferred_boundary_model_v6_1","open_compliance_if_used_as_is_v6_1","reverse_engineer_if_proprietary_core_needed_v6_1","copyleft_strategy_confidence_v6_1","copyleft_manual_review_trigger_v6_1","as_is_incorporation_sensible_v6_1","v6_2_sre_layer","v6_2_sre_stratum","v6_2_sre_role","v6_2_sre_family","v6_2_related_kali_package","v6_2_related_upstream_repo","v6_2_kali_package_suffices_for_tool_execution","v6_2_upstream_repo_preferred_for_deep_eval","v6_2_index_page_followup_useful","v6_2_index_page_followup_reason","v6_2_sre_notes","v6_2_dnspy_ilspy_relevance","v6_3_source_of_truth","v6_3_merge_note"
|
||||
"HactarCE/Hyperspeedcube","https://github.com/HactarCE/Hyperspeedcube","HyperTwist","Locked Foundation","nD / hypercubing simulation substrate","P0","20","9203","2.0","160.0","193.0","high","Keep the core engine or major subsystem mostly intact; change wrappers, branding, storage/auth, and integration seams so it becomes a first-class part of the target stack. For this repo class, that usually means preserving generalized puzzle/state/render logic while building a new application shell around it.","integrate","direct","Validate whether HactarCE/Hyperspeedcube truly deserves its current foundation-tier role for HyperTwist; extract the irreducible core abstractions, extension points, and transplantable subsystems.","state representation, move engine, notation parser, solver interfaces, renderer/projection abstraction, serialization/save formats, input mapping, performance/accuracy tradeoffs","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for higher-dimensional state/notation representations, projection math, renderer abstractions, puzzle serialization, controls, and replay/training hooks.","Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.","Integrate as a hypercubing / nD simulation subsystem for HyperTwist. Preserve the strongest existing pieces — nD state model, move notation, renderer, projection controls, solver/traversal logic, puzzle serialization, replay — and expose them behind a portfolio-stable interface. Wire first into cubing/cubing.js, then into tao-yu/Alg-Trainer for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: cubing/cubing.js, tao-yu/Alg-Trainer, poliva/cubedex.","Repurpose here means: turn it into a higher-dimensional renderer/simulator donor and shared interaction grammar for HyperTwist and long-horizon VectorShell.","cubing/cubing.js","3D engine + notation/state donor","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","tao-yu/Alg-Trainer","training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cross-project transfer candidate","future merger","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","VectorShell | ScriptoriumAI","VectorShell can borrow spatial/rendering and perception primitives; ScriptoriumAI can borrow tutorial/educational visualization patterns rather than the full engine.","Keep current tier unless source audit reveals architectural shallowness, hard-coded assumptions, missing extension points, or brittle internals.","Downgrade if core capabilities are thinner than claimed, architecture is too brittle or narrow, maintenance reality is poor, or the differentiating thesis collapses under code inspection.","Architecture note + salvage map + integration recipe + reclassification verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo; Relevant project-locked board sheet. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","HactarCE/Hyperspeedcube is placed in Locked Foundation for HyperTwist because it best serves the 'nD / hypercubing simulation substrate' role; recommended action is 'integrate' with repurposing scope 'direct'. Confidence is high because this remains a metadata-level judgment until source audit confirms hidden modules, plugin points, adapters, or architectural strengths.","Primary architectural anchor for HyperTwist; strongest current fit in corpus for the 'nD / hypercubing simulation substrate' role and should be source-audited before alternative bases.","Audit HactarCE/Hyperspeedcube as a hypercubing / nD engine candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations. Decide whether the best extraction path is direct and whether it belongs as foundation engine / simulation donor. Test the three merger paths in order: 1) cubing/cubing.js [3D engine + notation/state donor]; 2) tao-yu/Alg-Trainer [training UX donor]; 3) cross-project transfer candidate [future merger]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_hyper_engine_0001","HT_hyper_engine","hactarce/hyperspeedcube","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","yes","hypertwist_and_scriptoriumai","HyperTwist","HyperTwist & ScriptoriumAI.txt","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","Existing v5 row reaffirmed or widened by v6 supplemental intake.","v6_unified_source_of_truth_pack","2","1","160.0","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","Direct embed, vendored module, package dependency, or tightly integrated adapter as the architecture requires.","Typically preserve notices, attribution, and license text where required; no special copyleft-driven disclosure posture is normally needed.","Usually unnecessary unless you later decide the existing implementation is too constraining architecturally.","high","strategic-or-implemented-component","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Merged v6.1 copyleft layer and v6.2 SRE layer; use v6.3 docs + workbook as canonical handoff."
|
||||
"kkoomen/qbr","https://github.com/kkoomen/qbr","HyperTwist","Locked Foundation","Live cube-recognition substrate","P0","21","9204","4.0","158.0","191.0","high","Keep the core engine or major subsystem mostly intact; change wrappers, branding, storage/auth, and integration seams so it becomes a first-class part of the target stack. For this repo class, that usually means preserving calibration/detection/state-reconstruction logic while replacing camera UX and integration surfaces.","integrate","direct","Validate whether kkoomen/qbr truly deserves its current foundation-tier role for HyperTwist; extract the irreducible core abstractions, extension points, and transplantable subsystems.","puzzle model, learning flow, UX loops, data schema, replay/export, plugin/hooks","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for calibration routines, detection heuristics/models, color/state normalization, replay serialization, solver bridges, camera abstraction layers, and debug visualizations.","Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.","Integrate as a computer vision / AR subsystem for HyperTwist. Preserve the strongest existing pieces — camera ingest, calibration, segmentation/detection, pose or facelet extraction, state normalization, solver bridge, replay overlay, AR anchors — and expose them behind a portfolio-stable interface. Wire first into vivaansinghvi07/rubix-cube-solver, then into cubing/cubing.js for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: vivaansinghvi07/rubix-cube-solver, cubing/cubing.js, HactarCE/Hyperspeedcube.","Repurpose here means: turn it into a perception microservice, cube-state API, replay generator, or AR overlay donor for HyperTwist.","vivaansinghvi07/rubix-cube-solver","perception + replay donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cubing/cubing.js","state/render backend","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","cross-project transfer candidate","future merger","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","VectorShell | ScriptoriumAI","VectorShell can borrow spatial/rendering and perception primitives; ScriptoriumAI can borrow tutorial/educational visualization patterns rather than the full engine.","Keep current tier unless source audit reveals architectural shallowness, hard-coded assumptions, missing extension points, or brittle internals.","Downgrade if core capabilities are thinner than claimed, architecture is too brittle or narrow, maintenance reality is poor, or the differentiating thesis collapses under code inspection.","Architecture note + salvage map + integration recipe + reclassification verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo; Relevant project-locked board sheet. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","kkoomen/qbr is placed in Locked Foundation for HyperTwist because it best serves the 'Live cube-recognition substrate' role; recommended action is 'integrate' with repurposing scope 'direct'. Confidence is high because this remains a metadata-level judgment until source audit confirms hidden modules, plugin points, adapters, or architectural strengths.","Primary architectural anchor for HyperTwist; strongest current fit in corpus for the 'Live cube-recognition substrate' role and should be source-audited before alternative bases.","Audit kkoomen/qbr as a vision / perception / AR candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts. Decide whether the best extraction path is direct and whether it belongs as foundation engine / vision donor. Test the three merger paths in order: 1) vivaansinghvi07/rubix-cube-solver [perception + replay donor]; 2) cubing/cubing.js [state/render backend]; 3) cross-project transfer candidate [future merger]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_cube_vision_0001","HT_cube_vision","kkoomen/qbr","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","1","158.0","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","Direct embed, vendored module, package dependency, or tightly integrated adapter as the architecture requires.","Typically preserve notices, attribution, and license text where required; no special copyleft-driven disclosure posture is normally needed.","Usually unnecessary unless you later decide the existing implementation is too constraining architecturally.","high","strategic-or-implemented-component","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Merged v6.1 copyleft layer and v6.2 SRE layer; use v6.3 docs + workbook as canonical handoff."
|
||||
"vivaansinghvi07/rubix-cube-solver","https://github.com/vivaansinghvi07/rubix-cube-solver","HyperTwist","Locked Parallel Foundation","Vision / reconstruction donor layer","P0","22","9205","8.0","158.0","191.0","high","Keep the core engine or major subsystem mostly intact; change wrappers, branding, storage/auth, and integration seams so it becomes a first-class part of the target stack. For this repo class, that usually means preserving calibration/detection/state-reconstruction logic while replacing camera UX and integration surfaces.","integrate","direct","Validate whether vivaansinghvi07/rubix-cube-solver truly deserves its current foundation-tier role for HyperTwist; extract the irreducible core abstractions, extension points, and transplantable subsystems.","image pipeline, detection heuristics/models, cube-state reconstruction, calibration, temporal smoothing, replay model, solver handoff, AR/overlay hooks","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for calibration routines, detection heuristics/models, color/state normalization, replay serialization, solver bridges, camera abstraction layers, and debug visualizations.","Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.","Integrate as a computer vision / AR subsystem for HyperTwist. Preserve the strongest existing pieces — camera ingest, calibration, segmentation/detection, pose or facelet extraction, state normalization, solver bridge, replay overlay, AR anchors — and expose them behind a portfolio-stable interface. Wire first into kkoomen/qbr, then into cubing/cubing.js for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: kkoomen/qbr, cubing/cubing.js, HactarCE/Hyperspeedcube.","Repurpose here means: turn it into a perception microservice, cube-state API, replay generator, or AR overlay donor for HyperTwist.","kkoomen/qbr","foundation + perception donor","Use this repo against the partner as an augmenting layer; preserve the partner as the likely base and mine this repo for capabilities that improve breadth, UX, or specialization.","cubing/cubing.js","state/render backend","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","cross-project transfer candidate","future merger","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","VectorShell | ScriptoriumAI","VectorShell can borrow spatial/rendering and perception primitives; ScriptoriumAI can borrow tutorial/educational visualization patterns rather than the full engine.","Keep current tier unless source audit reveals architectural shallowness, hard-coded assumptions, missing extension points, or brittle internals.","Downgrade if core capabilities are thinner than claimed, architecture is too brittle or narrow, maintenance reality is poor, or the differentiating thesis collapses under code inspection.","Architecture note + salvage map + integration recipe + reclassification verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo; Relevant project-locked board sheet. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","vivaansinghvi07/rubix-cube-solver is placed in Locked Parallel Foundation for HyperTwist because it best serves the 'Parallel foundation and reconstruction companion donor' role; recommended action is 'integrate' with repurposing scope 'direct'. Confidence is high because this remains a metadata-level judgment until source audit confirms hidden modules, plugin points, adapters, or architectural strengths.","Part of the irreducible core stack for HyperTwist; kept as the parallel foundation and strongest reconstruction companion to qbr.","Audit vivaansinghvi07/rubix-cube-solver as a vision / perception / AR candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts. Decide whether the best extraction path is direct and whether it belongs as foundation engine / vision donor. Test the three merger paths in order: 1) kkoomen/qbr [foundation + perception donor]; 2) cubing/cubing.js [state/render backend]; 3) cross-project transfer candidate [future merger]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_cube_vision_0002","HT_cube_vision","vivaansinghvi07/rubix-cube-solver","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","1","158.0","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","Direct embed, vendored module, package dependency, or tightly integrated adapter as the architecture requires.","Typically preserve notices, attribution, and license text where required; no special copyleft-driven disclosure posture is normally needed.","Usually unnecessary unless you later decide the existing implementation is too constraining architecturally.","high","strategic-or-implemented-component","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Normalized legacy wording to dossier-backed parallel-foundation posture on 2026-04-25."
|
||||
"tao-yu/Alg-Trainer","https://github.com/tao-yu/Alg-Trainer","HyperTwist","Locked Parallel Foundation","Training / timing layer","P0","23","9206","9.0","156.0","189.0","high","Keep the core engine or major subsystem mostly intact; change wrappers, branding, storage/auth, and integration seams so it becomes a first-class part of the target stack. For this repo class, that usually means preserving cube-state, scramble, scheduling, or timer internals while adapting pedagogy, analytics, and UI.","integrate","direct","Validate whether tao-yu/Alg-Trainer truly deserves its current foundation-tier role for HyperTwist; extract the irreducible core abstractions, extension points, and transplantable subsystems.","algorithm database, weighted scheduling, spaced repetition, scramble generation, timing/statistics model, case metadata, import/export, smartcube adapters","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for algorithm databases, spaced-repetition logic, scramble generation, timer/stat code, virtual cube components, smartcube adapters, and custom-trainer configuration support.","Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.","Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into poliva/cubedex, then into Lykos/cube_trainer for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: poliva/cubedex, Lykos/cube_trainer, cubing/cubing.js.","Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist.","poliva/cubedex","specialized training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Lykos/cube_trainer","sampling/analytics donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cross-project transfer candidate","future merger","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","project-local first","Cross-project transfer is possible, but the value is clearest inside the assigned project until source audit exposes more reusable primitives.","Keep current tier unless source audit reveals architectural shallowness, hard-coded assumptions, missing extension points, or brittle internals.","Downgrade if core capabilities are thinner than claimed, architecture is too brittle or narrow, maintenance reality is poor, or the differentiating thesis collapses under code inspection.","Architecture note + salvage map + integration recipe + reclassification verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo; Relevant project-locked board sheet. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","tao-yu/Alg-Trainer is placed in Locked Parallel Foundation for HyperTwist because it best serves the 'Training / timing layer' role; recommended action is 'integrate' with repurposing scope 'direct'. Confidence is high because this remains a metadata-level judgment until source audit confirms hidden modules, plugin points, adapters, or architectural strengths.","Part of the irreducible core stack for HyperTwist; complements a primary foundation in the 'Training / timing layer' role and should be preserved in the committed build path.","Audit tao-yu/Alg-Trainer as a cubing trainer / solver / timing candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters. Decide whether the best extraction path is direct and whether it belongs as foundation engine / training donor. Test the three merger paths in order: 1) poliva/cubedex [specialized training UX donor]; 2) Lykos/cube_trainer [sampling/analytics donor]; 3) cross-project transfer candidate [future merger]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_training_stack_0001","HT_training_stack","tao-yu/alg-trainer","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","1","156.0","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","Direct embed, vendored module, package dependency, or tightly integrated adapter as the architecture requires.","Typically preserve notices, attribution, and license text where required; no special copyleft-driven disclosure posture is normally needed.","Usually unnecessary unless you later decide the existing implementation is too constraining architecturally.","high","strategic-or-implemented-component","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Merged v6.1 copyleft layer and v6.2 SRE layer; use v6.3 docs + workbook as canonical handoff."
|
||||
"cubing/cubing.js","https://github.com/cubing/cubing.js","HyperTwist","Locked Strategic Donor","Boundary-sensitive classic-cubing semantics and rendering donor","P1","24","9207","7.0","152.0","185.0","high","Keep the core engine or major subsystem mostly intact; change wrappers, branding, storage/auth, and integration seams so it becomes a first-class part of the target stack. For this repo class, that usually means preserving scene/layout primitives and replacing surrounding data models or backend assumptions.","integrate","direct","Validate whether cubing/cubing.js truly deserves its current foundation-tier role for HyperTwist; extract the irreducible core abstractions, extension points, and transplantable subsystems.","state representation, move engine, notation parser, solver interfaces, renderer/projection abstraction, serialization/save formats, input mapping, performance/accuracy tradeoffs","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for reusable canvas/editor components, design tokens, state models, keyboard shortcuts, drag/drop, accessibility, virtualization, and polished interaction patterns.","Inspect scene graph/canvas data model; layout primitives; component library; keyboard/gesture interactions; import/export schema; theming; plugin or extension hooks.","Integrate as a ui / design / frontend subsystem for HyperTwist. Preserve the strongest existing pieces — component library, canvas/animation engine, interaction patterns, layout/state models, accessibility hooks, theming, editor widgets — and expose them behind a portfolio-stable interface. Wire first into HactarCE/Hyperspeedcube, then into kkoomen/qbr for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: HactarCE/Hyperspeedcube, kkoomen/qbr.","Repurpose here means: turn it into a frontend interaction donor, canvas/editor pattern library, or polished shell layer on top of existing anchors.","project-local anchor","base + donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","shared portfolio utility","augmenter","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cross-project transfer candidate","future merger","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","VectorShell | HyperTwist | ScriptoriumAI","This capability is broadly portable across the portfolio because interaction, orchestration, and shell/UI patterns can be shared with thin domain adapters.","Keep current tier unless source audit reveals architectural shallowness, hard-coded assumptions, missing extension points, or brittle internals.","Downgrade if core capabilities are thinner than claimed, architecture is too brittle or narrow, maintenance reality is poor, or the differentiating thesis collapses under code inspection.","Architecture note + salvage map + integration recipe + reclassification verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo; Relevant project-locked board sheet. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep as the canonical classic-cubing semantics and interop donor, but only through its practical MPL path or bounded adapter/package consumption.","Dual MPL/GPL classic-cubing anchor with strong donor value, but not a carefree private-source fork candidate.","Audit cubing/cubing.js as a interface / visualization / shell surface candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect scene graph/canvas data model; layout primitives; component library; keyboard/gesture interactions; import/export schema; theming; plugin or extension hooks. Decide whether the best extraction path is direct and whether it belongs as foundation engine / visualization donor. Test the three merger paths in order: 1) project-local anchor [base + donor]; 2) shared portfolio utility [augmenter]; 3) cross-project transfer candidate [future merger]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_cube_semantics_0001","HT_cube_semantics","cubing/cubing.js","","","","","","","Original global P0-P3 source audit retained","MPL-2.0 OR GPL-3.0-or-later","known_from_reference_material","uploaded_reference_docs","yes","hypertwist_and_scriptoriumai","HyperTwist","HyperTwist & ScriptoriumAI.txt","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","Existing v5 row reaffirmed or widened by v6 supplemental intake.","v6_unified_source_of_truth_pack","2","1","152.0","mixed_or_boundary_sensitive_known","bounded_sidecar_or_selective_reimplementation","The repo is dual-licensed MPL-2.0 OR GPL-3.0-or-later. HyperTwist can consume it as a package or bounded adapter under the MPL side, but should avoid a carefree deep private source fork of upstream files.","Prefer package/dependency consumption or a bounded adapter seam under the MPL side; avoid deep private forks of upstream source files.","Preserve MPL notices and publish modifications to MPL-covered files when distribution obligations apply; avoid assuming the GPL side is the intended operational path.","Only if you later need to replace narrow upstream-covered seams with first-party equivalents or avoid carrying MPL-governed source modifications.","high","dual-license-boundary-review","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Assigned to HT_cube_semantics during cluster normalization on 2026-04-25."
|
||||
"cubing/alg.js","https://github.com/cubing/alg.js","HyperTwist","Donor Bench","Focused restrictive clean-room donor target","P2","25","9208","0.0","95.0","95.0","medium","Moderate modification. Treat cubing/alg.js as a family-level donor for HyperTwist: extract the implementation layer that matches its strongest domain contribution, preserve its protocols/data models/CLI or renderer boundaries, and adapt only the surface integration needed for HyperTwist rather than rewriting it wholesale.","repurpose","architecture only","Determine the real reusable value of cubing/alg.js for HyperTwist and decide whether it should be promoted, retained, or demoted in the v6 corpus.","Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.","Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.","Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.","Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training.","Consolidate by HyperTwist layer: core puzzle logic, scramblers/algs, renderer/bindings, XR/game-engine surfaces, experiments/comparators.","Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters.","HactarCE/Hyperspeedcube","foundation repo + feature donor","Use cubing/alg.js as a HyperTwist donor into HactarCE/Hyperspeedcube for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","cubing/cubing.js","engine repo + interface donor","Use cubing/alg.js as a HyperTwist donor into cubing/cubing.js for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","kkoomen/qbr","feature extraction only","Use cubing/alg.js as a HyperTwist donor into kkoomen/qbr for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","multi-project","Audit for hidden abstractions that travel across projects.","Source reveals a strong reusable subsystem, extensibility layer, protocol boundary, renderer core, data model, or automation surface that clearly strengthens one of the project stacks.","Source reveals the repo is mostly documentation, thin wrappers, packaging glue, stale scaffolding, or a weak duplicate with no meaningful transplantable subsystem.","Source-audit note, role recommendation, hidden-value extraction, exact integration path, and reclassification decision.","Implemented capability; hidden reusable modules; strongest integration path; strongest merger path; upgrade triggers; downgrade triggers; final recommended bucket.","Use v6 unified board + P0 tier packet + project design language + relevant family references.","Keep as its own clean-room donor lane because it isolates parser, AST, traversal, validation, keyboard-move, and URL/interchange semantics.","Standalone GPL parser/AST package with focused semantics value best preserved through Model A / Model B separation.","Inspect cubing/alg.js directly in source. Do not dismiss for license. Preserve nuanced distinctions between donor, reserve, comparator, and exclusion.","HT_cube_semantics_0002","HT_cube_semantics","cubing/alg.js","supplemental_v6_not_runtime_anchored","","","","","no","v6_unified_source_of_truth_pack","GPL-3.0-or-later","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","","","2","1","95.0","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The repo is GPL-3.0-or-later and should remain a focused clean-room donor lane rather than direct donor code. Preserve the parser/AST/traversal semantics through a scrubbed Model A handoff only.","Model A may inspect the restrictive source; Model B should implement only from a scrubbed first-party specification.","Direct incorporation would require GPL-compatible distribution/compliance and is not the planned HyperTwist path.","Yes — preferred path for reproducing parser/AST/traversal semantics in first-party code.","high","gpl-clean-room-donor","no","","","","","","","","","","","","","v6.3_final_source_of_truth","Assigned to HT_cube_semantics during cluster normalization on 2026-04-25."
|
||||
"cubing/twisty.js","https://github.com/cubing/twisty.js","HyperTwist","Donor Bench","Focused restrictive clean-room donor target","P2","27","9210","0.0","95.0","95.0","medium","Moderate modification. Treat cubing/twisty.js as a family-level donor for HyperTwist: extract the implementation layer that matches its strongest domain contribution, preserve its protocols/data models/CLI or renderer boundaries, and adapt only the surface integration needed for HyperTwist rather than rewriting it wholesale.","repurpose","architecture only","Determine the real reusable value of cubing/twisty.js for HyperTwist and decide whether it should be promoted, retained, or demoted in the v6 corpus.","Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.","Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.","Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.","Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training.","Consolidate by HyperTwist layer: core puzzle logic, scramblers/algs, renderer/bindings, XR/game-engine surfaces, experiments/comparators.","Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters.","HactarCE/Hyperspeedcube","foundation repo + feature donor","Use cubing/twisty.js as a HyperTwist donor into HactarCE/Hyperspeedcube for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","cubing/cubing.js","engine repo + interface donor","Use cubing/twisty.js as a HyperTwist donor into cubing/cubing.js for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","kkoomen/qbr","feature extraction only","Use cubing/twisty.js as a HyperTwist donor into kkoomen/qbr for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","multi-project","Audit for hidden abstractions that travel across projects.","Source reveals a strong reusable subsystem, extensibility layer, protocol boundary, renderer core, data model, or automation surface that clearly strengthens one of the project stacks.","Source reveals the repo is mostly documentation, thin wrappers, packaging glue, stale scaffolding, or a weak duplicate with no meaningful transplantable subsystem.","Source-audit note, role recommendation, hidden-value extraction, exact integration path, and reclassification decision.","Implemented capability; hidden reusable modules; strongest integration path; strongest merger path; upgrade triggers; downgrade triggers; final recommended bucket.","Use v6 unified board + P0 tier packet + project design language + relevant family references.","Keep as its own clean-room donor lane because it isolates browser twisty-viewer/player shell behavior and control-bar semantics.","Standalone GPL viewer/player shell with focused browser twisty behavior best preserved through Model A / Model B separation.","Inspect cubing/twisty.js directly in source. Do not dismiss for license. Preserve nuanced distinctions between donor, reserve, comparator, and exclusion.","HT_cube_semantics_0003","HT_cube_semantics","cubing/twisty.js","supplemental_v6_not_runtime_anchored","","","","","no","v6_unified_source_of_truth_pack","GPL-3.0-or-later","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","","","2","1","95.0","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The repo is GPL-3.0-or-later and should remain a focused clean-room donor lane rather than direct donor code. Preserve viewer/player shell, scrubber, and twisty-element behavior through a scrubbed Model A handoff only.","Model A may inspect the restrictive source; Model B should implement only from a scrubbed first-party specification.","Direct incorporation would require GPL-compatible distribution/compliance and is not the planned HyperTwist path.","Yes — preferred path for reproducing compact twisty-viewer behavior in first-party code.","high","gpl-clean-room-donor","no","","","","","","","","","","","","","v6.3_final_source_of_truth","Assigned to HT_cube_semantics during cluster normalization on 2026-04-25."
|
||||
"cahidenes/rubiks-cube-solver","https://github.com/cahidenes/rubiks-cube-solver","HyperTwist","Locked Strategic Donor","Vision / reconstruction donor layer","P1","55","9211","4.0","148.0","174.0","high","Keep the core engine or major subsystem mostly intact; change wrappers, branding, storage/auth, and integration seams so it becomes a first-class part of the target stack. For this repo class, that usually means preserving calibration/detection/state-reconstruction logic while replacing camera UX and integration surfaces.","integrate","direct","Confirm the donor thesis for cahidenes/rubiks-cube-solver in HyperTwist: what should be harvested, how tightly it couples to the current stack, and whether it should ever be promoted upward.","image pipeline, detection heuristics/models, cube-state reconstruction, calibration, temporal smoothing, replay model, solver handoff, AR/overlay hooks","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for calibration routines, detection heuristics/models, color/state normalization, replay serialization, solver bridges, camera abstraction layers, and debug visualizations.","Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.","Integrate as a computer vision / AR subsystem for HyperTwist. Preserve the strongest existing pieces — camera ingest, calibration, segmentation/detection, pose or facelet extraction, state normalization, solver bridge, replay overlay, AR anchors — and expose them behind a portfolio-stable interface. Wire first into kkoomen/qbr, then into vivaansinghvi07/rubix-cube-solver for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: kkoomen/qbr, vivaansinghvi07/rubix-cube-solver, cubing/cubing.js.","Repurpose here means: turn it into a perception microservice, cube-state API, replay generator, or AR overlay donor for HyperTwist.","kkoomen/qbr","foundation + perception donor","Use this repo against the partner as an augmenting layer; preserve the partner as the likely base and mine this repo for capabilities that improve breadth, UX, or specialization.","vivaansinghvi07/rubix-cube-solver","perception + replay donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cubing/cubing.js","state/render backend","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","VectorShell | ScriptoriumAI","VectorShell can borrow spatial/rendering and perception primitives; ScriptoriumAI can borrow tutorial/educational visualization patterns rather than the full engine.","Keep current tier unless source audit reveals architectural shallowness, hard-coded assumptions, missing extension points, or brittle internals.","Downgrade if valuable capability is too entangled to salvage, too shallow, duplicated better elsewhere, or far weaker than the current donor thesis.","Donor extraction note + merge recipe + reclassification verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo; Relevant project-locked board sheet. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","cahidenes/rubiks-cube-solver is placed in Locked Strategic Donor for HyperTwist because it best serves the 'Active recognition-heuristics and validation donor' role; recommended action is 'integrate' with repurposing scope 'direct'. Confidence is high because this remains a metadata-level judgment until source audit confirms hidden modules, plugin points, adapters, or architectural strengths.","High-value active vision donor for recognition heuristics, solver-bridge normalization, and validation behind qbr and vivaansinghvi07; not a foundation anchor.","Audit cahidenes/rubiks-cube-solver as a vision / perception / AR candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts. Decide whether the best extraction path is direct and whether it belongs as foundation engine / vision donor. Test the three merger paths in order: 1) kkoomen/qbr [foundation + perception donor]; 2) vivaansinghvi07/rubix-cube-solver [perception + replay donor]; 3) cubing/cubing.js [state/render backend]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_cube_vision_0003","HT_cube_vision","cahidenes/rubiks-cube-solver","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","2","148.0","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","Direct embed, vendored module, package dependency, or tightly integrated adapter as the architecture requires.","Typically preserve notices, attribution, and license text where required; no special copyleft-driven disclosure posture is normally needed.","Usually unnecessary unless you later decide the existing implementation is too constraining architecturally.","high","strategic-or-implemented-component","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Normalized legacy candidate-core wording to dossier-backed strategic-donor posture on 2026-04-25."
|
||||
"tentone/rubix-solver","https://github.com/tentone/rubix-solver","HyperTwist","Locked Strategic Donor","Vision / reconstruction donor layer","P1","56","9212","5.0","148.0","174.0","high","Keep the core engine or major subsystem mostly intact; change wrappers, branding, storage/auth, and integration seams so it becomes a first-class part of the target stack. For this repo class, that usually means preserving calibration/detection/state-reconstruction logic while replacing camera UX and integration surfaces.","integrate","direct","Confirm the donor thesis for tentone/rubix-solver in HyperTwist: what should be harvested, how tightly it couples to the current stack, and whether it should ever be promoted upward.","image pipeline, detection heuristics/models, cube-state reconstruction, calibration, temporal smoothing, replay model, solver handoff, AR/overlay hooks","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for calibration routines, detection heuristics/models, color/state normalization, replay serialization, solver bridges, camera abstraction layers, and debug visualizations.","Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.","Integrate as a computer vision / AR subsystem for HyperTwist. Preserve the strongest existing pieces — camera ingest, calibration, segmentation/detection, pose or facelet extraction, state normalization, solver bridge, replay overlay, AR anchors — and expose them behind a portfolio-stable interface. Wire first into kkoomen/qbr, then into vivaansinghvi07/rubix-cube-solver for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: kkoomen/qbr, vivaansinghvi07/rubix-cube-solver, cubing/cubing.js.","Repurpose here means: turn it into a perception microservice, cube-state API, replay generator, or AR overlay donor for HyperTwist.","kkoomen/qbr","foundation + perception donor","Use this repo against the partner as an augmenting layer; preserve the partner as the likely base and mine this repo for capabilities that improve breadth, UX, or specialization.","vivaansinghvi07/rubix-cube-solver","perception + replay donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cubing/cubing.js","state/render backend","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","VectorShell | ScriptoriumAI","VectorShell can borrow spatial/rendering and perception primitives; ScriptoriumAI can borrow tutorial/educational visualization patterns rather than the full engine.","Keep current tier unless source audit reveals architectural shallowness, hard-coded assumptions, missing extension points, or brittle internals.","Downgrade if valuable capability is too entangled to salvage, too shallow, duplicated better elsewhere, or far weaker than the current donor thesis.","Donor extraction note + merge recipe + reclassification verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo; Relevant project-locked board sheet. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","tentone/rubix-solver is placed in Locked Strategic Donor for HyperTwist because it best serves the 'Active native-CV donor and comparison bench' role; recommended action is 'integrate' with repurposing scope 'direct'. Confidence is high because this remains a metadata-level judgment until source audit confirms hidden modules, plugin points, adapters, or architectural strengths.","High-value active native-CV donor for detection heuristics and comparison benchmarking behind the vision anchors; not a foundation anchor.","Audit tentone/rubix-solver as a vision / perception / AR candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts. Decide whether the best extraction path is direct and whether it belongs as foundation engine / vision donor. Test the three merger paths in order: 1) kkoomen/qbr [foundation + perception donor]; 2) vivaansinghvi07/rubix-cube-solver [perception + replay donor]; 3) cubing/cubing.js [state/render backend]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_cube_vision_0004","HT_cube_vision","tentone/rubix-solver","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","2","148.0","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","Direct embed, vendored module, package dependency, or tightly integrated adapter as the architecture requires.","Typically preserve notices, attribution, and license text where required; no special copyleft-driven disclosure posture is normally needed.","Usually unnecessary unless you later decide the existing implementation is too constraining architecturally.","high","strategic-or-implemented-component","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Normalized legacy candidate-core wording to dossier-backed strategic-donor posture on 2026-04-25."
|
||||
"Lykos/cube_trainer","https://github.com/Lykos/cube_trainer","HyperTwist","Locked Strategic Donor","Training / timing layer","P1","57","9213","14.0","145.0","171.0","high","Keep the core engine or major subsystem mostly intact; change wrappers, branding, storage/auth, and integration seams so it becomes a first-class part of the target stack. For this repo class, that usually means preserving cube-state, scramble, scheduling, or timer internals while adapting pedagogy, analytics, and UI.","integrate","direct","Confirm the donor thesis for Lykos/cube_trainer in HyperTwist: what should be harvested, how tightly it couples to the current stack, and whether it should ever be promoted upward.","algorithm database, weighted scheduling, spaced repetition, scramble generation, timing/statistics model, case metadata, import/export, smartcube adapters","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for algorithm databases, spaced-repetition logic, scramble generation, timer/stat code, virtual cube components, smartcube adapters, and custom-trainer configuration support.","Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.","Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: tao-yu/Alg-Trainer, poliva/cubedex, cubing/cubing.js.","Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist.","tao-yu/Alg-Trainer","base + donor swarm","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","poliva/cubedex","specialized training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cross-project transfer candidate","future merger","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","project-local first","Cross-project transfer is possible, but the value is clearest inside the assigned project until source audit exposes more reusable primitives.","Keep current tier unless source audit reveals architectural shallowness, hard-coded assumptions, missing extension points, or brittle internals.","Downgrade if valuable capability is too entangled to salvage, too shallow, duplicated better elsewhere, or far weaker than the current donor thesis.","Donor extraction note + merge recipe + reclassification verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo; Relevant project-locked board sheet. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Lykos/cube_trainer is placed in Locked Strategic Donor for HyperTwist because it best serves the 'Top-tier persistent training-domain donor' role; recommended action is 'integrate' with repurposing scope 'direct'. Confidence is high because this remains a metadata-level judgment until source audit confirms hidden modules, plugin points, adapters, or architectural strengths.","Top-tier strategic donor for the persistent training-session, statistics, personalization, and advanced BLD-oriented coaching-backend domain.","Audit Lykos/cube_trainer as a cubing trainer / solver / timing candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters. Decide whether the best extraction path is direct and whether it belongs as foundation engine / training donor. Test the three merger paths in order: 1) tao-yu/Alg-Trainer [base + donor swarm]; 2) poliva/cubedex [specialized training UX donor]; 3) cross-project transfer candidate [future merger]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_training_stack_0002","HT_training_stack","lykos/cube_trainer","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","2","145.0","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","Direct embed, vendored module, package dependency, or tightly integrated adapter as the architecture requires.","Typically preserve notices, attribution, and license text where required; no special copyleft-driven disclosure posture is normally needed.","Usually unnecessary unless you later decide the existing implementation is too constraining architecturally.","high","strategic-or-implemented-component","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Normalized legacy candidate-core wording to dossier-backed strategic-donor posture on 2026-04-25."
|
||||
"kash/cubedesk","https://github.com/kash/cubedesk","HyperTwist","Locked Strategic Donor","Restrictive clean-room donor target","P1","58","9214","16.0","145.0","171.0","high","Keep the core engine or major subsystem mostly intact; change wrappers, branding, storage/auth, and integration seams so it becomes a first-class part of the target stack. For this repo class, that usually means preserving generalized puzzle/state/render logic while building a new application shell around it.","repurpose","architecture only","Confirm the donor thesis for kash/cubedesk in HyperTwist: what should be harvested, how tightly it couples to the current stack, and whether it should ever be promoted upward.","algorithm database, weighted scheduling, spaced repetition, scramble generation, timing/statistics model, case metadata, import/export, smartcube adapters","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for higher-dimensional state/notation representations, projection math, renderer abstractions, puzzle serialization, controls, and replay/training hooks.","Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.","Integrate as a hypercubing / nD simulation subsystem for HyperTwist. Preserve the strongest existing pieces — nD state model, move notation, renderer, projection controls, solver/traversal logic, puzzle serialization, replay — and expose them behind a portfolio-stable interface. Wire first into HactarCE/Hyperspeedcube, then into cubing/cubing.js for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: HactarCE/Hyperspeedcube, cubing/cubing.js, tao-yu/Alg-Trainer.","Repurpose here means: turn it into a higher-dimensional renderer/simulator donor and shared interaction grammar for HyperTwist and long-horizon VectorShell.","HactarCE/Hyperspeedcube","foundation + donor","Use this repo against the partner as an augmenting layer; preserve the partner as the likely base and mine this repo for capabilities that improve breadth, UX, or specialization.","cubing/cubing.js","3D engine + notation/state donor","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","tao-yu/Alg-Trainer","training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","VectorShell | ScriptoriumAI","VectorShell can borrow spatial/rendering and perception primitives; ScriptoriumAI can borrow tutorial/educational visualization patterns rather than the full engine.","Keep current tier unless source audit reveals architectural shallowness, hard-coded assumptions, missing extension points, or brittle internals.","Downgrade if valuable capability is too entangled to salvage, too shallow, duplicated better elsewhere, or far weaker than the current donor thesis.","Donor extraction note + merge recipe + reclassification verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo; Relevant project-locked board sheet. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep as a strategic clean-room donor because the product breadth is unusually strong, but the conflicting license signals block carefree donor treatment.","Broad cubing product platform with high strategic value, but the repo must stay in restrictive clean-room custody because README/LICENSE say GPL while package.json says All Rights Reserved.","Audit kash/cubedesk as a hypercubing / nD engine candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations. Decide whether the best extraction path is direct and whether it belongs as foundation engine / simulation donor. Test the three merger paths in order: 1) HactarCE/Hyperspeedcube [foundation + donor]; 2) cubing/cubing.js [3D engine + notation/state donor]; 3) tao-yu/Alg-Trainer [training UX donor]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_hyper_engine_0002","HT_hyper_engine","kash/cubedesk","","","","","","","Original global P0-P3 source audit retained","GPLv3-or-later in README/LICENSE; package.json says All Rights Reserved","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","2","145.0","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The repo has conflicting license signals and should remain in restrictive clean-room custody. Treat it as a strategic product-pattern and subsystem extraction target, not as direct donor code.","Model A may inspect and extract product/subsystem behavior; Model B should implement only from a scrubbed first-party specification.","Do not incorporate directly until the license contradiction is fully resolved; current HyperTwist posture is clean-room donor only.","Yes — this is the preferred path because the strategic value is broad but direct reuse is blocked by the contradictory license posture.","high","license-contradiction-clean-room-donor","no","","","","","","","","","","","","","v6.3_final_source_of_truth","Corrected on 2026-04-25 from stale direct-donor posture to dossier-backed restrictive clean-room strategic donor status."
|
||||
"poliva/cubedex","https://github.com/poliva/cubedex","HyperTwist","Locked Strategic Donor","Training / timing layer","P1","59","9215","15.0","145.0","171.0","high","Keep the core engine or major subsystem mostly intact; change wrappers, branding, storage/auth, and integration seams so it becomes a first-class part of the target stack. For this repo class, that usually means preserving scene/layout primitives and replacing surrounding data models or backend assumptions.","integrate","direct","Confirm the donor thesis for poliva/cubedex in HyperTwist: what should be harvested, how tightly it couples to the current stack, and whether it should ever be promoted upward.","algorithm database, weighted scheduling, spaced repetition, scramble generation, timing/statistics model, case metadata, import/export, smartcube adapters","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for algorithm databases, spaced-repetition logic, scramble generation, timer/stat code, virtual cube components, smartcube adapters, and custom-trainer configuration support.","Inspect scene graph/canvas data model; layout primitives; component library; keyboard/gesture interactions; import/export schema; theming; plugin or extension hooks.","Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into Lykos/cube_trainer for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: tao-yu/Alg-Trainer, Lykos/cube_trainer, cubing/cubing.js.","Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist.","project-local anchor","base + donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","shared portfolio utility","augmenter","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cross-project transfer candidate","future merger","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","VectorShell | HyperTwist | ScriptoriumAI","This capability is broadly portable across the portfolio because interaction, orchestration, and shell/UI patterns can be shared with thin domain adapters.","Keep current tier unless source audit reveals architectural shallowness, hard-coded assumptions, missing extension points, or brittle internals.","Downgrade if valuable capability is too entangled to salvage, too shallow, duplicated better elsewhere, or far weaker than the current donor thesis.","Donor extraction note + merge recipe + reclassification verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo; Relevant project-locked board sheet. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","poliva/cubedex is placed in Locked Strategic Donor for HyperTwist because it best serves the 'Top-tier training UX and smartcube donor' role; recommended action is 'integrate' with repurposing scope 'direct'. Confidence is high because this remains a metadata-level judgment until source audit confirms hidden modules, plugin points, adapters, or architectural strengths.","Top-tier strategic donor for smartcube-aware, offline-first training UX and practical drill ergonomics, but not the owner of the long-term training backend.","Audit poliva/cubedex as a interface / visualization / shell surface candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect scene graph/canvas data model; layout primitives; component library; keyboard/gesture interactions; import/export schema; theming; plugin or extension hooks. Decide whether the best extraction path is direct and whether it belongs as foundation engine / visualization donor. Test the three merger paths in order: 1) project-local anchor [base + donor]; 2) shared portfolio utility [augmenter]; 3) cross-project transfer candidate [future merger]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_training_stack_0016","HT_training_stack","poliva/cubedex","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","2","145.0","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","Direct embed, vendored module, package dependency, or tightly integrated adapter as the architecture requires.","Typically preserve notices, attribution, and license text where required; no special copyleft-driven disclosure posture is normally needed.","Usually unnecessary unless you later decide the existing implementation is too constraining architecturally.","high","strategic-or-implemented-component","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Assigned from legacy HY_misc to HT_training_stack during cluster normalization on 2026-04-25."
|
||||
"cs0x7f/cstimer","https://github.com/cs0x7f/cstimer","HyperTwist","Reserve Bench","Gold-standard timer benchmark","P2","60","9216","22.0","121.0","147.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving cube-state, scramble, scheduling, or timer internals while adapting pedagogy, analytics, and UI.","future candidate","architecture only","Capture the timer, persistence, statistics, and hardware-support behaviors that make cstimer the gold-standard timer benchmark for HyperTwist.","Timer transitions, persistence, statistics, reconstruction, scramble flow, and smart-device surfaces as benchmark material.","Inspect timer-state transitions, solve/session persistence, statistics/reconstruction surfaces, scramble integration, and smart-device behavior as benchmark material only.","Which timer behaviors, persistence expectations, and solve-analysis surfaces should become first-party acceptance criteria?","Keep as a restrictive benchmark. Use it as the timer behavior reference point for HyperTwist, not as donor code.","Do not merge this repo into the HyperTwist core. Translate only high-level timer and stats expectations into first-party implementations.","Repurpose here means: derive acceptance-test targets and product expectations for timer flow, persistence, statistics, and hardware support.","tao-yu/Alg-Trainer","base + donor swarm","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","poliva/cubedex","specialized training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Lykos/cube_trainer","sampling/analytics donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Reference only","Retain only as benchmark, oracle, acceptance-test, or clean-room planning input.","Keep current tier unless source audit reveals architectural shallowness, hard-coded assumptions, missing extension points, or brittle internals.","Downgrade if valuable capability is too entangled to salvage, too shallow, duplicated better elsewhere, or far weaker than the current donor thesis.","Benchmark note + salvage list + clear do-not-incorporate boundary.","1) What specific benchmark value remains in cs0x7f/cstimer
|
||||
2) What must stay benchmark-only or clean-room-only
|
||||
3) Acceptance-test, oracle, or behavior targets worth preserving","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo; Relevant project-locked board sheet. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep in canon as the strongest restrictive timer benchmark; use it to calibrate first-party timer and stats behavior.","GPL timer/training platform whose value is product expectations, acceptance tests, and behavior benchmarking rather than donor use.","Audit cs0x7f/cstimer only as a restrictive gold-standard timer benchmark for HyperTwist. Extract behavior expectations and acceptance criteria, not donor code.","HT_timer_training_0001","HT_timer_training","cs0x7f/cstimer","","","","","","","Original global P0-P3 source audit retained","GPL-3.0","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","2","121.0","mixed_or_boundary_sensitive_known","pattern_only_preferred","The repo is GPL timer/training software and the current HyperTwist posture is benchmark-only. Use it to define behavioral expectations and acceptance criteria, not for direct code incorporation.","Reference only: benchmark timer and statistics behavior without direct source incorporation.","Direct incorporation would require GPL-compatible distribution/compliance and is not the planned HyperTwist path.","Only if a narrow timer behavior later proves strategically necessary to recreate in first-party code; otherwise keep this as a benchmark.","high","gpl-timer-benchmark","no","","","","","","","","","","","","","v6.3_final_source_of_truth","Corrected on 2026-04-25 from stale donor posture to dossier-backed gold-standard timer benchmark status."
|
||||
"cutelyaware/magiccube4d","https://github.com/cutelyaware/magiccube4d/tree/master","HyperTwist","Locked Strategic Donor","Top-tier 4D interaction, history, and macro donor with attribution obligations","P1","7463","9218","49.0","122.0","137.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving generalized puzzle/state/render logic while building a new application shell around it.","repurpose","moderate modification","Determine whether cutelyaware/magiccube4d should stay donor/merge-tier for HyperTwist, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","puzzle model, learning flow, UX loops, data schema, replay/export, plugin/hooks","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for higher-dimensional state/notation representations, projection math, renderer abstractions, puzzle serialization, controls, and replay/training hooks.","Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.","Integrate as a hypercubing / nD simulation subsystem for HyperTwist. Preserve the strongest existing pieces — nD state model, move notation, renderer, projection controls, solver/traversal logic, puzzle serialization, replay — and expose them behind a portfolio-stable interface. Wire first into HactarCE/Hyperspeedcube, then into cubing/cubing.js for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: HactarCE/Hyperspeedcube, cubing/cubing.js, tao-yu/Alg-Trainer.","Repurpose here means: turn it into a higher-dimensional renderer/simulator donor and shared interaction grammar for HyperTwist and long-horizon VectorShell.","HactarCE/Hyperspeedcube","foundation + donor","Use this repo against the partner as an augmenting layer; preserve the partner as the likely base and mine this repo for capabilities that improve breadth, UX, or specialization.","cubing/cubing.js","3D engine + notation/state donor","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","tao-yu/Alg-Trainer","training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","VectorShell | ScriptoriumAI","VectorShell can borrow spatial/rendering and perception primitives; ScriptoriumAI can borrow tutorial/educational visualization patterns rather than the full engine.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep as one of the most important legacy 4D interaction donors; the dossier-backed custom broad-use license is operationally usable, but attribution and provenance obligations must stay explicit.","Custom broad-use donor with strong 4D interaction/history/macro value and explicit attribution/provenance obligations.","Audit cutelyaware/magiccube4d as a hypercubing / nD engine candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations. Decide whether the best extraction path is moderate modification and whether it belongs as subsystem donor / simulation donor. Test the three merger paths in order: 1) HactarCE/Hyperspeedcube [foundation + donor]; 2) cubing/cubing.js [3D engine + notation/state donor]; 3) tao-yu/Alg-Trainer [training UX donor]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_hyper_engine_0003","HT_hyper_engine","cutelyaware/magiccube4d","","","","","","","Original global P0-P3 source audit retained","Custom broad-use license with attribution requested","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","122.0","mixed_or_boundary_sensitive_known","direct_incorporation_ok","The repo is operationally usable because the custom license explicitly allows use, modification, and redistribution, but attribution and provenance obligations must be preserved and tracked.","Direct donor use is acceptable with explicit attribution and provenance tracking; keep the MyMath.java provenance note visible in license tracking.","Preserve the custom license text, requested attribution, and the provenance note for utility code with referenced GPL lineage.","Usually unnecessary unless later isolating a narrow seam is cleaner than carrying the legacy code directly.","medium","custom-license-attribution-review","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Corrected on 2026-04-25 from stale unknown-license merge-bench posture to dossier-backed usable custom-license donor status."
|
||||
"roice3/Magic120Cell","https://github.com/roice3/Magic120Cell","HyperTwist","Locked Strategic Donor","Specialized 4D interaction and puzzle-UX donor","P1","7464","9219","49.0","122.0","137.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving generalized puzzle/state/render logic while building a new application shell around it.","repurpose","moderate modification","Determine whether roice3/Magic120Cell should stay donor/merge-tier for HyperTwist, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","puzzle model, learning flow, UX loops, data schema, replay/export, plugin/hooks","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for higher-dimensional state/notation representations, projection math, renderer abstractions, puzzle serialization, controls, and replay/training hooks.","Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.","Integrate as a hypercubing / nD simulation subsystem for HyperTwist. Preserve the strongest existing pieces — nD state model, move notation, renderer, projection controls, solver/traversal logic, puzzle serialization, replay — and expose them behind a portfolio-stable interface. Wire first into HactarCE/Hyperspeedcube, then into cubing/cubing.js for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: HactarCE/Hyperspeedcube, cubing/cubing.js, tao-yu/Alg-Trainer.","Repurpose here means: turn it into a higher-dimensional renderer/simulator donor and shared interaction grammar for HyperTwist and long-horizon VectorShell.","HactarCE/Hyperspeedcube","foundation + donor","Use this repo against the partner as an augmenting layer; preserve the partner as the likely base and mine this repo for capabilities that improve breadth, UX, or specialization.","cubing/cubing.js","3D engine + notation/state donor","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","tao-yu/Alg-Trainer","training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","VectorShell | ScriptoriumAI","VectorShell can borrow spatial/rendering and perception primitives; ScriptoriumAI can borrow tutorial/educational visualization patterns rather than the full engine.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep as a specialized 4D interaction and puzzle-UX donor; the dossier-backed MIT posture and source richness justify promotion above the old merge-bench treatment.","MIT specialized 4D donor with real interaction, visibility/filtering, save/load, and puzzle-UX value.","Audit roice3/Magic120Cell as a hypercubing / nD engine candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations. Decide whether the best extraction path is moderate modification and whether it belongs as subsystem donor / simulation donor. Test the three merger paths in order: 1) HactarCE/Hyperspeedcube [foundation + donor]; 2) cubing/cubing.js [3D engine + notation/state donor]; 3) tao-yu/Alg-Trainer [training UX donor]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_hyper_engine_0004","HT_hyper_engine","roice3/magic120cell","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","122.0","permissive_or_noncopyleft_known","direct_incorporation_ok","The repo is MIT and should remain a specialized 4D interaction donor. Direct donor use is legally straightforward if HyperTwist wants to preserve its dedicated UX and puzzle-handling surfaces.","Direct donor use or bounded extraction are both acceptable; choose the seam that best preserves specialized 4D interaction behavior.","Preserve MIT notices and attribution where required.","Usually unnecessary unless later replacing a narrow seam is cleaner than carrying the upstream code.","high","permissive-specialized-donor","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Corrected on 2026-04-25 from stale unknown-license merge-bench posture to dossier-backed MIT specialized donor status."
|
||||
"roice3/MagicCube5D","https://github.com/roice3/MagicCube5D","HyperTwist","Locked Strategic Donor","Specialized 5D cube interaction, progress, and macro donor","P1","7465","9220","50.0","122.0","137.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving generalized puzzle/state/render logic while building a new application shell around it.","repurpose","moderate modification","Determine whether roice3/MagicCube5D should stay donor/merge-tier for HyperTwist, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","puzzle model, learning flow, UX loops, data schema, replay/export, plugin/hooks","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for higher-dimensional state/notation representations, projection math, renderer abstractions, puzzle serialization, controls, and replay/training hooks.","Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.","Integrate as a hypercubing / nD simulation subsystem for HyperTwist. Preserve the strongest existing pieces — nD state model, move notation, renderer, projection controls, solver/traversal logic, puzzle serialization, replay — and expose them behind a portfolio-stable interface. Wire first into HactarCE/Hyperspeedcube, then into cubing/cubing.js for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: HactarCE/Hyperspeedcube, cubing/cubing.js, tao-yu/Alg-Trainer.","Repurpose here means: turn it into a higher-dimensional renderer/simulator donor and shared interaction grammar for HyperTwist and long-horizon VectorShell.","HactarCE/Hyperspeedcube","foundation + donor","Use this repo against the partner as an augmenting layer; preserve the partner as the likely base and mine this repo for capabilities that improve breadth, UX, or specialization.","cubing/cubing.js","3D engine + notation/state donor","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","tao-yu/Alg-Trainer","training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","VectorShell | ScriptoriumAI","VectorShell can borrow spatial/rendering and perception primitives; ScriptoriumAI can borrow tutorial/educational visualization patterns rather than the full engine.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep as a specialized 5D cube interaction and macro donor; the dossier-backed MIT posture and source richness justify promotion above the old merge-bench treatment.","MIT specialized 5D donor with real macro, progress, slice, and advanced interaction value.","Audit roice3/MagicCube5D as a hypercubing / nD engine candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations. Decide whether the best extraction path is moderate modification and whether it belongs as subsystem donor / simulation donor. Test the three merger paths in order: 1) HactarCE/Hyperspeedcube [foundation + donor]; 2) cubing/cubing.js [3D engine + notation/state donor]; 3) tao-yu/Alg-Trainer [training UX donor]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_hyper_engine_0005","HT_hyper_engine","roice3/magiccube5d","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","122.0","permissive_or_noncopyleft_known","direct_incorporation_ok","The repo is MIT and should remain a specialized 5D interaction donor. Direct donor use is legally straightforward if HyperTwist wants to preserve its advanced cube-specific UX and macro behavior.","Direct donor use or bounded extraction are both acceptable; choose the seam that best preserves specialized 5D interaction and macro behavior.","Preserve MIT notices and attribution where required.","Usually unnecessary unless later replacing a narrow seam is cleaner than carrying the upstream code.","high","permissive-specialized-donor","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Corrected on 2026-04-25 from stale unknown-license merge-bench posture to dossier-backed MIT specialized donor status."
|
||||
"aMonteSl/CodeXR","https://github.com/aMonteSl/CodeXR","HyperTwist","Reserve Bench","Reference-only XR benchmark","P3","7467","9222","51.0","119.0","134.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving calibration/detection/state-reconstruction logic while replacing camera UX and integration surfaces.","future candidate","architecture only","Validate that CodeXR remains reference-only and record the specific immersive interaction ideas worth preserving without direct source reuse.","Collaboration-room flow, scene launch, virtual screens, and immersive interaction behavior as benchmark material only.","Inspect XR launch flow, collaboration-room server patterns, virtual-screen behavior, and immersive UI choreography as benchmark material only.","Which interaction patterns are reusable at the behavior level without inheriting the code-analysis product identity or GPL source?","Keep in restrictive/reference custody. Use only as a benchmark for XR interaction ideas and immersive UI patterns; do not merge source into HyperTwist.","Do not treat this repo as part of the HyperTwist merge nucleus. If useful, translate isolated interaction ideas into first-party designs without inheriting the code-analysis shell.","Repurpose here means: abstract useful XR interaction ideas into first-party browser/XR surfaces without reusing source.","kkoomen/qbr","foundation + perception donor","Use this repo against the partner as an augmenting layer; preserve the partner as the likely base and mine this repo for capabilities that improve breadth, UX, or specialization.","vivaansinghvi07/rubix-cube-solver","perception + replay donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cubing/cubing.js","state/render backend","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","Reference only","Retain only as benchmark, oracle, acceptance-test, or clean-room planning input.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Benchmark note + salvage list + clear do-not-incorporate boundary.","1) What specific benchmark value remains in aMonteSl/CodeXR
|
||||
2) What must stay benchmark-only or clean-room-only
|
||||
3) Acceptance-test, oracle, or behavior targets worth preserving","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep in canon only as a reference-only XR benchmark; its value is in interaction ideas, not donor code.","GPL-3.0-only code-analysis XR extension with narrow benchmark value for immersive interaction patterns.","Audit aMonteSl/CodeXR only as a reference-only XR benchmark for HyperTwist. Do not recommend direct incorporation. Extract interaction patterns, collaboration metaphors, and virtual-screen ideas only.","HT_cube_vision_0005","HT_cube_vision","amontesl/codexr","","","","","","","Original global P0-P3 source audit retained","GPL-3.0-only","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","119.0","mixed_or_boundary_sensitive_known","pattern_only_preferred","The repo is GPL-3.0-only and, per the dossier-backed HyperTwist posture, is retained only as a reference benchmark. Study interaction patterns and behavior; do not plan direct code incorporation.","Reference only: use as a benchmark for interaction patterns and immersive UI ideas without direct source incorporation.","Direct incorporation would require GPL-compatible distribution/compliance and is not the planned HyperTwist path.","Only if a uniquely valuable interaction pattern later needs first-party recreation; otherwise keep this as a benchmark.","high","gpl-reference-only-benchmark","no","","","","","","","","","","","","","v6.3_final_source_of_truth","Corrected on 2026-04-25 from stale pre-dossier donor posture to dossier-backed GPL reference-only benchmark status."
|
||||
"brianpeiris/RiftSketch","https://github.com/brianpeiris/RiftSketch","HyperTwist","Reserve Bench","Adjacency / future transfer","P2","7468","9223","51.0","119.0","134.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving calibration/detection/state-reconstruction logic while replacing camera UX and integration surfaces.","future candidate","architecture only","Determine whether brianpeiris/RiftSketch should stay donor/merge-tier for HyperTwist, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","puzzle model, learning flow, UX loops, data schema, replay/export, plugin/hooks","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for algorithm databases, spaced-repetition logic, scramble generation, timer/stat code, virtual cube components, smartcube adapters, and custom-trainer configuration support.","Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.","Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer.","Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist.","kkoomen/qbr","foundation + perception donor","Use this repo against the partner as an augmenting layer; preserve the partner as the likely base and mine this repo for capabilities that improve breadth, UX, or specialization.","vivaansinghvi07/rubix-cube-solver","perception + replay donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cubing/cubing.js","state/render backend","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","VectorShell | ScriptoriumAI","VectorShell can borrow spatial/rendering and perception primitives; ScriptoriumAI can borrow tutorial/educational visualization patterns rather than the full engine.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","brianpeiris/RiftSketch is placed in Reserve Bench for HyperTwist because it best serves the 'XR interaction and spatial-UI bench' role; recommended action is 'future candidate' with repurposing scope 'architecture only'. Confidence is medium because this remains a metadata-level judgment until source audit confirms hidden modules, plugin points, adapters, or architectural strengths.","Useful MIT WebXR interaction benchmark for spatial editor panels, world-space monitors, and keyboard-first immersive tooling, but explicitly below the HyperTwist core tier.","Audit brianpeiris/RiftSketch as a vision / perception / AR candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts. Decide whether the best extraction path is moderate modification and whether it belongs as subsystem donor / vision donor. Test the three merger paths in order: 1) kkoomen/qbr [foundation + perception donor]; 2) vivaansinghvi07/rubix-cube-solver [perception + replay donor]; 3) cubing/cubing.js [state/render backend]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_cube_vision_0006","HT_cube_vision","brianpeiris/riftsketch","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","119.0","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","Direct embed, vendored module, package dependency, or tightly integrated adapter as the architecture requires.","Typically preserve notices, attribution, and license text where required; no special copyleft-driven disclosure posture is normally needed.","Usually unnecessary unless you later decide the existing implementation is too constraining architecturally.","high","strategic-or-implemented-component","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Normalized legacy merge-bench wording to dossier-backed below-core benchmark posture on 2026-04-25."
|
||||
"MathewKJ2048/Rubiks-cube-simulator","https://github.com/MathewKJ2048/Rubiks-cube-simulator","HyperTwist","Reserve Bench","Clean-room simulator benchmark","P3","7469","9224","51.0","118.0","133.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving cube-state, scramble, scheduling, or timer internals while adapting pedagogy, analytics, and UI.","future candidate","architecture only","Capture the lightweight simulator behaviors worth preserving from MathewKJ2048/Rubiks-cube-simulator through a scrubbed clean-room spec.","Command grammar, move-history logging, beginner-solver flow, and timed step playback as clean-room benchmark material.","Inspect command grammar, move-history handling, beginner-solver flow, and timed step playback as clean-room benchmark material only.","Which lightweight simulator behaviors are worth preserving through a scrubbed Model A handoff?","Keep only as a clean-room benchmark. Use it to shape lightweight simulator behavior; do not incorporate source.","Do not treat this repo as a merge candidate. Convert useful simulator behaviors into a scrubbed Model A spec only.","Repurpose here means: derive first-party lightweight simulator behavior through a clean-room process.","tao-yu/Alg-Trainer","base + donor swarm","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","poliva/cubedex","specialized training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Lykos/cube_trainer","sampling/analytics donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Reference only","Retain only as benchmark, oracle, acceptance-test, or clean-room planning input.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Benchmark note + salvage list + clear do-not-incorporate boundary.","1) What specific benchmark value remains in MathewKJ2048/Rubiks-cube-simulator
|
||||
2) What must stay benchmark-only or clean-room-only
|
||||
3) Acceptance-test, oracle, or behavior targets worth preserving","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep in canon only as a low-priority clean-room simulator benchmark for lightweight simulator behaviors.","GPL simulator with narrow lightweight-behavior value; retain only as clean-room benchmark material.","Audit MathewKJ2048/Rubiks-cube-simulator only as a clean-room simulator benchmark. Extract behaviors into a scrubbed spec; do not recommend direct source incorporation.","HT_training_clean_room_0004","HT_training_clean_room","mathewkj2048/rubiks-cube-simulator","","","","","","","Original global P0-P3 source audit retained","GPL-3.0","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","118.0","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The repo is GPL simulator code. Retain it only as clean-room benchmark material and implement any strategically necessary simulator behavior from a scrubbed first-party specification.","Model A may inspect and summarize behavior; Model B should implement only from a scrubbed clean-room specification.","Direct incorporation would require GPL-compatible distribution/compliance and is not the planned HyperTwist path.","Yes — this is the preferred path if lightweight simulator behavior later proves strategically necessary.","high","gpl-clean-room-benchmark","no","","","","","","","","","","","","","v6.3_final_source_of_truth","Corrected on 2026-04-25 from stale donor posture to dossier-backed clean-room simulator benchmark status."
|
||||
"NuiLab/code-vr","https://github.com/NuiLab/code-vr","HyperTwist","Donor Bench","XR pedagogy and code-to-scene representation donor","P2","7470","9225","51.0","118.0","133.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving calibration/detection/state-reconstruction logic while replacing camera UX and integration surfaces.","repurpose","moderate modification","Determine whether NuiLab/code-vr should stay donor/merge-tier for HyperTwist, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","puzzle model, learning flow, UX loops, data schema, replay/export, plugin/hooks","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for algorithm databases, spaced-repetition logic, scramble generation, timer/stat code, virtual cube components, smartcube adapters, and custom-trainer configuration support.","Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.","Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer.","Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist.","kkoomen/qbr","foundation + perception donor","Use this repo against the partner as an augmenting layer; preserve the partner as the likely base and mine this repo for capabilities that improve breadth, UX, or specialization.","vivaansinghvi07/rubix-cube-solver","perception + replay donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cubing/cubing.js","state/render backend","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","VectorShell | ScriptoriumAI","VectorShell can borrow spatial/rendering and perception primitives; ScriptoriumAI can borrow tutorial/educational visualization patterns rather than the full engine.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep below core tier as an XR pedagogy and code-to-scene representation donor; the teaching frame and app/service split matter more than the under-construction product shell.","MIT XR pedagogy repo with interesting teaching and code-to-scene patterns, but too under-construction and off-domain to justify merge-bench treatment.","Audit NuiLab/code-vr as a vision / perception / AR candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts. Decide whether the best extraction path is moderate modification and whether it belongs as subsystem donor / vision donor. Test the three merger paths in order: 1) kkoomen/qbr [foundation + perception donor]; 2) vivaansinghvi07/rubix-cube-solver [perception + replay donor]; 3) cubing/cubing.js [state/render backend]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_cube_vision_0007","HT_cube_vision","nuilab/code-vr","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","118.0","permissive_or_noncopyleft_known","direct_incorporation_ok","The repo is MIT and direct use is legally straightforward, but the current HyperTwist posture is still below-core donor use because the strongest value is in XR pedagogy, embodied onboarding, and code-to-scene boundary ideas rather than product-core ownership.","Use selectively as a donor or bounded adapter where the XR pedagogy and code-to-scene representation ideas materially shorten build time.","Preserve MIT notices and attribution where required.","Usually unnecessary unless later replacing a narrow implementation seam is architecturally cleaner than carrying the upstream code.","high","below-core-mit-donor","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Corrected on 2026-04-25 from stale merge-bench posture to dossier-backed below-core XR pedagogy donor status."
|
||||
"ShellPuppy/RCube","https://github.com/ShellPuppy/RCube","HyperTwist","Reserve Bench","Large-N solver benchmark","P3","7471","9226","51.0","118.0","133.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving cube-state, scramble, scheduling, or timer internals while adapting pedagogy, analytics, and UI.","future candidate","architecture only","Document the large-N orientation and stage-framing ideas that justify retaining RCube only as a benchmark row.","Large-cube orientation logic, stage framing, and solver behavior as benchmark material.","Inspect large-cube orientation logic, stage structure, and output/reporting surfaces as benchmark material only.","Which large-cube orientation and stage strategies are worth preserving as benchmark knowledge?","Keep as a restrictive large-N solver benchmark. Use it for algorithm/reference comparison, not as donor code.","Do not treat this repo as a merge candidate. Translate only large-cube orientation and stage-framing ideas into first-party work if later needed.","Repurpose here means: use as an algorithm/reference benchmark for large-cube state and orientation tricks.","tao-yu/Alg-Trainer","base + donor swarm","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","poliva/cubedex","specialized training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Lykos/cube_trainer","sampling/analytics donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Reference only","Retain only as benchmark, oracle, acceptance-test, or clean-room planning input.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Benchmark note + salvage list + clear do-not-incorporate boundary.","1) What specific benchmark value remains in ShellPuppy/RCube
|
||||
2) What must stay benchmark-only or clean-room-only
|
||||
3) Acceptance-test, oracle, or behavior targets worth preserving","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep in canon only as a restrictive benchmark for large-N state/orientation techniques.","GPL large-N solver with narrow algorithm/reference value and no donor-case for the HyperTwist product core.","Audit ShellPuppy/RCube only as a restrictive large-N solver benchmark. Extract algorithm ideas and acceptance-test expectations, not donor code.","HT_solver_oracles_0001","HT_solver_oracles","shellpuppy/rcube","","","","","","","Original global P0-P3 source audit retained","GPL-3.0","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","118.0","mixed_or_boundary_sensitive_known","pattern_only_preferred","The repo is GPL large-N solver code and is retained only as an algorithm/reference benchmark. Use it for comparison and expectations, not direct source incorporation.","Reference only: use as a large-N solver benchmark without direct source incorporation.","Direct incorporation would require GPL-compatible distribution/compliance and is not the planned HyperTwist path.","Only if a later first-party large-N lane needs recreation of a narrow behavior or algorithmic framing; otherwise keep this as a benchmark.","high","gpl-large-n-benchmark","no","","","","","","","","","","","","","v6.3_final_source_of_truth","Corrected on 2026-04-25 from stale donor posture to dossier-backed large-N solver benchmark status."
|
||||
"abunickabhi/5style-Trainer","https://github.com/abunickabhi/5style-Trainer","HyperTwist","Donor Bench","Training / timing layer","P2","7472","9227","51.0","118.0","133.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving cube-state, scramble, scheduling, or timer internals while adapting pedagogy, analytics, and UI.","repurpose","moderate modification","Determine whether abunickabhi/5style-Trainer should stay donor/merge-tier for HyperTwist, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","algorithm database, weighted scheduling, spaced repetition, scramble generation, timing/statistics model, case metadata, import/export, smartcube adapters","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for algorithm databases, spaced-repetition logic, scramble generation, timer/stat code, virtual cube components, smartcube adapters, and custom-trainer configuration support.","Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.","Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer.","Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist.","tao-yu/Alg-Trainer","base + donor swarm","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","poliva/cubedex","specialized training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Lykos/cube_trainer","sampling/analytics donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","project-local first","Cross-project transfer is possible, but the value is clearest inside the assigned project until source audit exposes more reusable primitives.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","abunickabhi/5style-Trainer is placed in Donor Bench for HyperTwist because it best serves the 'Focused advanced-training donor' role; recommended action is 'repurpose' with repurposing scope 'moderate modification'. Confidence is medium because this remains a metadata-level judgment until source audit confirms hidden modules, plugin points, adapters, or architectural strengths.","Focused advanced-training donor for 5-style and BLD-specific case packs, subset structures, and niche practice flow rather than a broader training-platform shell.","Audit abunickabhi/5style-Trainer as a cubing trainer / solver / timing candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters. Decide whether the best extraction path is moderate modification and whether it belongs as subsystem donor / training donor. Test the three merger paths in order: 1) tao-yu/Alg-Trainer [base + donor swarm]; 2) poliva/cubedex [specialized training UX donor]; 3) Lykos/cube_trainer [sampling/analytics donor]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_training_stack_0006","HT_training_stack","abunickabhi/5style-trainer","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","118.0","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","Direct embed, vendored module, package dependency, or tightly integrated adapter as the architecture requires.","Typically preserve notices, attribution, and license text where required; no special copyleft-driven disclosure posture is normally needed.","Usually unnecessary unless you later decide the existing implementation is too constraining architecturally.","high","strategic-or-implemented-component","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Normalized legacy merge-bench wording to dossier-backed focused advanced-training donor posture on 2026-04-25."
|
||||
"brownan/Rubiks-Cube-Solver","https://github.com/brownan/Rubiks-Cube-Solver","HyperTwist","Reserve Bench","Benchmark oracle and clean-room optimal-solver candidate","P2","7473","9228","51.0","118.0","133.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving cube-state, scramble, scheduling, or timer internals while adapting pedagogy, analytics, and UI.","future candidate","architecture only","Determine whether brownan/Rubiks-Cube-Solver should stay donor/merge-tier for HyperTwist, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","puzzle model, learning flow, UX loops, data schema, replay/export, plugin/hooks","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for algorithm databases, spaced-repetition logic, scramble generation, timer/stat code, virtual cube components, smartcube adapters, and custom-trainer configuration support.","Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.","Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer.","Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist.","tao-yu/Alg-Trainer","base + donor swarm","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","poliva/cubedex","specialized training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Lykos/cube_trainer","sampling/analytics donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","project-local first","Cross-project transfer is possible, but the value is clearest inside the assigned project until source audit exposes more reusable primitives.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep as a primary benchmark oracle and secondary clean-room optimal-solver candidate; the dossier-backed GPL posture blocks donor treatment but not benchmark/oracle and Model A value.","GPL solver/oracle repo whose retained value is correctness/oracle behavior plus a later clean-room optimal-solver lane.","Audit brownan/Rubiks-Cube-Solver as a cubing trainer / solver / timing candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters. Decide whether the best extraction path is moderate modification and whether it belongs as subsystem donor / training donor. Test the three merger paths in order: 1) tao-yu/Alg-Trainer [base + donor swarm]; 2) poliva/cubedex [specialized training UX donor]; 3) Lykos/cube_trainer [sampling/analytics donor]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_training_stack_0007","HT_training_stack","brownan/rubiks-cube-solver","","","","","","","Original global P0-P3 source audit retained","GPL-3.0","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","118.0","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The repo is GPL-3.0 and should remain a benchmark oracle plus clean-room optimal-solver candidate. Preserve correctness/oracle behavior and produce any first-party solver through a scrubbed clean-room process.","Use as an oracle and Model A source only; Model B should implement any optimal-solver work from a scrubbed first-party specification.","Direct incorporation would require GPL-compatible distribution/compliance and is not the planned HyperTwist path.","Yes — this is the preferred path for any later first-party optimal-solver effort.","high","gpl-oracle-clean-room-review","no","","","","","","","","","","","","","v6.3_final_source_of_truth","Corrected on 2026-04-25 from stale unknown-license merge-bench posture to dossier-backed benchmark-oracle and clean-room optimal-solver status."
|
||||
"newyork-anthonyng/rubiks-cross-trainer","https://github.com/newyork-anthonyng/rubiks-cross-trainer","HyperTwist","Donor Bench","Training / timing layer","P2","7475","9230","51.0","118.0","133.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving cube-state, scramble, scheduling, or timer internals while adapting pedagogy, analytics, and UI.","repurpose","moderate modification","Determine whether newyork-anthonyng/rubiks-cross-trainer should stay donor/merge-tier for HyperTwist, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","algorithm database, weighted scheduling, spaced repetition, scramble generation, timing/statistics model, case metadata, import/export, smartcube adapters","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for algorithm databases, spaced-repetition logic, scramble generation, timer/stat code, virtual cube components, smartcube adapters, and custom-trainer configuration support.","Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.","Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer.","Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist.","tao-yu/Alg-Trainer","base + donor swarm","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","poliva/cubedex","specialized training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Lykos/cube_trainer","sampling/analytics donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","project-local first","Cross-project transfer is possible, but the value is clearest inside the assigned project until source audit exposes more reusable primitives.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","newyork-anthonyng/rubiks-cross-trainer is placed in Donor Bench for HyperTwist because it best serves the 'Focused donor' role; recommended action is 'repurpose' with repurposing scope 'moderate modification'. Confidence is medium because this remains a metadata-level judgment until source audit confirms hidden modules, plugin points, adapters, or architectural strengths.","Focused donor for the precomputed cross-difficulty corpus and CFOP micro-drill progression rather than a broader training-platform shell.","Audit newyork-anthonyng/rubiks-cross-trainer as a cubing trainer / solver / timing candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters. Decide whether the best extraction path is moderate modification and whether it belongs as subsystem donor / training donor. Test the three merger paths in order: 1) tao-yu/Alg-Trainer [base + donor swarm]; 2) poliva/cubedex [specialized training UX donor]; 3) Lykos/cube_trainer [sampling/analytics donor]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_training_stack_0008","HT_training_stack","newyork-anthonyng/rubiks-cross-trainer","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","118.0","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","Direct embed, vendored module, package dependency, or tightly integrated adapter as the architecture requires.","Typically preserve notices, attribution, and license text where required; no special copyleft-driven disclosure posture is normally needed.","Usually unnecessary unless you later decide the existing implementation is too constraining architecturally.","high","strategic-or-implemented-component","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Normalized legacy merge-bench wording to dossier-backed focused-donor posture on 2026-04-25."
|
||||
"vwcwong/CubeSim","https://github.com/vwcwong/CubeSim","HyperTwist","Reserve Bench","Clean-room state/history benchmark","P3","7476","9231","51.0","118.0","133.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving cube-state, scramble, scheduling, or timer internals while adapting pedagogy, analytics, and UI.","future candidate","architecture only","Capture the state/history and replay behaviors worth preserving from vwcwong/CubeSim through a scrubbed clean-room spec.","State/history separation, parser/scramble modules, tests, and replay-oriented behavior as clean-room benchmark material.","Inspect cube-state/history split, parser and scramble modules, tests, and replay-oriented behavior as clean-room benchmark material only.","Which state/history and replay behaviors are worth preserving through a scrubbed Model A handoff?","Keep only as a clean-room benchmark. Use it to shape first-party state/history and replay behavior; do not incorporate source.","Do not treat this repo as a merge candidate. Convert useful state/history ideas into a scrubbed Model A spec only.","Repurpose here means: derive first-party state/history and replay behavior through a clean-room process.","tao-yu/Alg-Trainer","base + donor swarm","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","poliva/cubedex","specialized training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Lykos/cube_trainer","sampling/analytics donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Reference only","Retain only as benchmark, oracle, acceptance-test, or clean-room planning input.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Benchmark note + salvage list + clear do-not-incorporate boundary.","1) What specific benchmark value remains in vwcwong/CubeSim
|
||||
2) What must stay benchmark-only or clean-room-only
|
||||
3) Acceptance-test, oracle, or behavior targets worth preserving","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep in canon only as a clean-room state/history benchmark for first-party simulator architecture.","GPL simulator with unusually clean state/history architecture; retain only as clean-room benchmark material.","Audit vwcwong/CubeSim only as a clean-room state/history benchmark. Extract architectural behaviors into a scrubbed spec; do not recommend direct source incorporation.","HT_training_clean_room_0005","HT_training_clean_room","vwcwong/cubesim","","","","","","","Original global P0-P3 source audit retained","GPL-3.0","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","118.0","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The repo is GPL simulator code. Retain it only as clean-room benchmark material and implement any strategically necessary state/history behavior from a scrubbed first-party specification.","Model A may inspect and summarize behavior; Model B should implement only from a scrubbed clean-room specification.","Direct incorporation would require GPL-compatible distribution/compliance and is not the planned HyperTwist path.","Yes — this is the preferred path if state/history or replay behavior later proves strategically necessary.","high","gpl-clean-room-benchmark","no","","","","","","","","","","","","","v6.3_final_source_of_truth","Corrected on 2026-04-25 from stale donor posture to dossier-backed clean-room state/history benchmark status."
|
||||
"AviKaufman/Rubix-cube-trainer","https://github.com/AviKaufman/Rubix-cube-trainer","HyperTwist","Reserve Bench","Clean-room pedagogy benchmark","P3","7477","9232","52.0","117.0","132.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving cube-state, scramble, scheduling, or timer internals while adapting pedagogy, analytics, and UI.","future candidate","architecture only","Capture the teaching-flow and tutorial behaviors worth preserving from AviKaufman/Rubix-cube-trainer through a scrubbed clean-room spec.","Beginner-method sequencing, step guidance, and tutorial-state transitions as clean-room benchmark material.","Inspect beginner-method sequencing, step guidance, tutorial-state transitions, and 3D teaching behavior as clean-room benchmark material only.","Which teaching-flow and tutorial behaviors are worth preserving through a scrubbed Model A handoff?","Keep only as a clean-room benchmark. Use it to shape first-party pedagogy and tutorial behavior; do not incorporate source.","Do not treat this repo as a merge candidate. Convert useful teaching-flow ideas into a scrubbed Model A spec only.","Repurpose here means: derive first-party pedagogy and tutorial behavior through a clean-room process.","tao-yu/Alg-Trainer","base + donor swarm","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","poliva/cubedex","specialized training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Lykos/cube_trainer","sampling/analytics donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Reference only","Retain only as benchmark, oracle, acceptance-test, or clean-room planning input.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Benchmark note + salvage list + clear do-not-incorporate boundary.","1) What specific benchmark value remains in AviKaufman/Rubix-cube-trainer
|
||||
2) What must stay benchmark-only or clean-room-only
|
||||
3) Acceptance-test, oracle, or behavior targets worth preserving","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep in canon only as a clean-room pedagogy benchmark for first-party teaching-flow work.","All-rights-reserved repo with narrow teaching-flow value; retain only as clean-room benchmark material.","Audit AviKaufman/Rubix-cube-trainer only as a clean-room pedagogy benchmark. Extract tutorial behaviors into a scrubbed spec; do not recommend direct source incorporation.","HT_training_clean_room_0003","HT_training_clean_room","avikaufman/rubix-cube-trainer","","","","","","","Original global P0-P3 source audit retained","All Rights Reserved","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","117.0","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The repo is all-rights-reserved. Retain it only as clean-room benchmark material and implement any strategically necessary tutorial behavior from a scrubbed first-party specification.","Model A may inspect and summarize behavior; Model B should implement only from a scrubbed clean-room specification.","Do not incorporate source or assets directly without separate rights.","Yes — this is the preferred path if pedagogy and tutorial behavior later prove strategically necessary.","high","all-rights-reserved-clean-room-benchmark","no","","","","","","","","","","","","","v6.3_final_source_of_truth","Corrected on 2026-04-25 from stale donor posture to dossier-backed clean-room pedagogy benchmark status."
|
||||
"alinen/cube","https://github.com/alinen/cube","HyperTwist","Reserve Bench","Clean-room planner benchmark","P3","7478","9233","52.0","117.0","132.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving cube-state, scramble, scheduling, or timer internals while adapting pedagogy, analytics, and UI.","future candidate","architecture only","Capture the planner and guided-lesson behaviors worth preserving from alinen/cube through a scrubbed clean-room spec.","Planner flow, guided lessons, cube-state handling, and bounded-search behavior as clean-room benchmark material.","Inspect planner logic, lesson flow, cube-state handling, and bounded-search behavior as clean-room benchmark material only.","Which planner and lesson behaviors are worth preserving through a scrubbed Model A handoff?","Keep only as a clean-room benchmark. Use it to shape first-party planner and guided-lesson behavior; do not incorporate source.","Do not treat this repo as a merge candidate. Convert useful planner and lesson ideas into scrubbed Model A specifications only.","Repurpose here means: derive first-party planner and guided-lesson behavior through a clean-room process.","tao-yu/Alg-Trainer","base + donor swarm","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","poliva/cubedex","specialized training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Lykos/cube_trainer","sampling/analytics donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Reference only","Retain only as benchmark, oracle, acceptance-test, or clean-room planning input.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Benchmark note + salvage list + clear do-not-incorporate boundary.","1) What specific benchmark value remains in alinen/cube
|
||||
2) What must stay benchmark-only or clean-room-only
|
||||
3) Acceptance-test, oracle, or behavior targets worth preserving","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep in canon only as a clean-room planner benchmark for first-party guided-lesson and planner work.","No explicit license visible and limited scope; retain only for clean-room planner behavior extraction.","Audit alinen/cube only as a clean-room planner benchmark. Extract planner behaviors and guided-lesson flow into a scrubbed spec; do not recommend direct source incorporation.","HT_training_clean_room_0001","HT_training_clean_room","alinen/cube","","","","","","","Original global P0-P3 source audit retained","no explicit license visible","pending_repo_license_audit","not_resolved_from_uploaded_materials","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","117.0","license_unknown_pending","reverse_engineer_preferred","No explicit permissive license is visible. Retain this repo only as clean-room benchmark material and implement any strategically necessary behavior from a scrubbed first-party specification.","Model A may inspect and summarize behavior; Model B should implement only from a scrubbed clean-room specification.","Do not incorporate source directly without a confirmed license grant.","Yes — this is the preferred path if planner or lesson behavior later proves strategically necessary.","medium","no-license-clean-room-benchmark","no","","","","","","","","","","","","","v6.3_final_source_of_truth","Corrected on 2026-04-25 from stale donor posture to dossier-backed clean-room planner benchmark status."
|
||||
"ambisinister/blindsolve","https://github.com/ambisinister/blindsolve","HyperTwist","Reserve Bench","Clean-room BLD memo benchmark","P3","7479","9234","52.0","117.0","132.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving cube-state, scramble, scheduling, or timer internals while adapting pedagogy, analytics, and UI.","future candidate","architecture only","Capture the memo-practice and feedback behaviors worth preserving from blindsolve through a scrubbed clean-room spec.","Memo-practice flow, feedback behavior, and narrow training-state transitions as clean-room benchmark material.","Inspect memo-practice flow, prompt cadence, scoring/feedback behavior, and narrow training-state transitions as clean-room benchmark material only.","Which memo-practice behaviors are worth preserving through a scrubbed Model A handoff?","Keep only as a clean-room benchmark. Use it to shape a first-party memo-practice micro-mode; do not incorporate source.","Do not treat this repo as a merge candidate. Convert useful memo-practice ideas into a scrubbed Model A spec only.","Repurpose here means: derive first-party BLD memo-practice behavior through a clean-room process.","tao-yu/Alg-Trainer","base + donor swarm","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","poliva/cubedex","specialized training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Lykos/cube_trainer","sampling/analytics donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Reference only","Retain only as benchmark, oracle, acceptance-test, or clean-room planning input.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Benchmark note + salvage list + clear do-not-incorporate boundary.","1) What specific benchmark value remains in ambisinister/blindsolve
|
||||
2) What must stay benchmark-only or clean-room-only
|
||||
3) Acceptance-test, oracle, or behavior targets worth preserving","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep in canon only as a clean-room BLD memo benchmark for later first-party micro-mode work.","No explicit license visible and extremely narrow scope; retain only as clean-room benchmark material.","Audit ambisinister/blindsolve only as a clean-room BLD memo benchmark. Extract memo-practice behavior into a scrubbed spec; do not recommend direct source incorporation.","HT_training_clean_room_0002","HT_training_clean_room","ambisinister/blindsolve","","","","","","","Original global P0-P3 source audit retained","no explicit license visible","pending_repo_license_audit","not_resolved_from_uploaded_materials","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","117.0","license_unknown_pending","reverse_engineer_preferred","No explicit permissive license is visible. Retain this repo only as clean-room benchmark material and implement any strategically necessary memo-practice behavior from a scrubbed first-party specification.","Model A may inspect and summarize behavior; Model B should implement only from a scrubbed clean-room specification.","Do not incorporate source directly without a confirmed license grant.","Yes — this is the preferred path if a memo-practice micro-mode later proves strategically necessary.","medium","no-license-clean-room-benchmark","no","","","","","","","","","","","","","v6.3_final_source_of_truth","Corrected on 2026-04-25 from stale donor posture to dossier-backed clean-room BLD memo benchmark status."
|
||||
"efrantar/rob-twophase","https://github.com/efrantar/rob-twophase","HyperTwist","Reserve Bench","Solver oracle and robot-metric benchmark","P2","7480","9235","52.0","117.0","132.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving cube-state, scramble, scheduling, or timer internals while adapting pedagogy, analytics, and UI.","future candidate","architecture only","Capture the correctness, metric, and oracle behaviors that justify keeping rob-twophase only as a benchmark row.","Robot metrics, pruning tables, CLI oracle behavior, and multiple-solution search as benchmark material.","Inspect metric handling, pruning-table structure, CLI oracle behavior, and multiple-solution search as benchmark material only.","Which oracle surfaces, robot metrics, and correctness/performance baselines should be preserved for first-party solver validation?","Keep as a restrictive solver oracle benchmark. Use it for correctness, metric comparison, and performance expectations; do not treat it as donor code.","Do not merge this repo into the HyperTwist core. Translate only oracle behavior and robot-metric expectations into first-party acceptance tests.","Repurpose here means: use as a correctness/performance oracle and robot-metric benchmark.","tao-yu/Alg-Trainer","base + donor swarm","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","poliva/cubedex","specialized training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Lykos/cube_trainer","sampling/analytics donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Reference only","Retain only as benchmark, oracle, acceptance-test, or clean-room planning input.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Benchmark note + salvage list + clear do-not-incorporate boundary.","1) What specific benchmark value remains in efrantar/rob-twophase
|
||||
2) What must stay benchmark-only or clean-room-only
|
||||
3) Acceptance-test, oracle, or behavior targets worth preserving","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep in canon as a restrictive solver oracle benchmark with robot-metric value.","GPL solver/oracle repo whose retained value is correctness, performance, and metric benchmarking rather than donor use.","Audit efrantar/rob-twophase only as a restrictive solver oracle and robot-metric benchmark. Extract acceptance-test expectations and oracle behavior, not donor code.","HT_solver_oracles_0002","HT_solver_oracles","efrantar/rob-twophase","","","","","","","Original global P0-P3 source audit retained","GPL-3.0","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","117.0","mixed_or_boundary_sensitive_known","pattern_only_preferred","The repo is GPL solver/oracle code and the current HyperTwist posture is benchmark-only. Use it for correctness, metric, and performance comparison rather than direct source incorporation.","Reference only: use as a solver oracle and robot-metric benchmark without direct source incorporation.","Direct incorporation would require GPL-compatible distribution/compliance and is not the planned HyperTwist path.","Only if a narrow oracle behavior later needs first-party recreation; otherwise keep this as a benchmark.","high","gpl-solver-oracle-benchmark","no","","","","","","","","","","","","","v6.3_final_source_of_truth","Corrected on 2026-04-25 from stale donor posture to dossier-backed solver oracle benchmark status."
|
||||
"onionhoney/roux-trainers","https://github.com/onionhoney/roux-trainers","HyperTwist","Donor Bench","Focused restrictive clean-room donor target","P2","7481","9236","52.0","117.0","132.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving cube-state, scramble, scheduling, or timer internals while adapting pedagogy, analytics, and UI.","repurpose","architecture only","Capture the stage-specific training, analyzer, recognition, and drill-loop behaviors that justify keeping roux-trainers as a clean-room donor target.","Stage-specific training flows, solver-backed analyzer logic, recognition masking, favorites/batch-drill persistence, and 2D/3D visualization boundaries.","Inspect blockbuilding micro-trainers, stage-specific state machines, solver-backed analyzer logic, recognition masking, favorites/batch-drill persistence, and 2D/3D visualization boundaries.","Which Roux-specific training and analyzer behaviors are strategically worth reproducing in first-party code through a clean-room handoff?","Keep in restrictive custody and route value through clean-room extraction only. Use it as a method-specific training and analyzer donor, not as direct donor code.","Do not merge this repo into the HyperTwist core as source. Convert the valuable training-state-machine and analyzer behaviors into first-party subsystems behind a clean-room boundary.","Repurpose here means: translate stage-specific training and analyzer behaviors into first-party implementations through a clean-room process.","tao-yu/Alg-Trainer","base + donor swarm","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","poliva/cubedex","specialized training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Lykos/cube_trainer","sampling/analytics donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","HyperTwist only","Restrictive clean-room donor value is real, but it should flow through Model A to a first-party implementation rather than through direct source sharing.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Model A salvage map + clean-room boundary note + first-party subsystem extraction plan.","1) Which stage-specific subsystems are worth preserving
|
||||
2) What must stay behind Model A / Model B separation
|
||||
3) What first-party implementations should replace the GPL source","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep in canon as a focused restrictive clean-room donor for method-specific training and analyzer behavior.","GPLv3 method-specific trainer with real subsystem value that should be preserved through clean-room extraction rather than donor use.","Audit onionhoney/roux-trainers as a focused restrictive clean-room donor for HyperTwist. Preserve method-specific training-state-machine, analyzer, recognition-masking, and drill-loop behavior in a scrubbed Model A handoff only.","HT_training_clean_room_0006","HT_training_clean_room","onionhoney/roux-trainers","","","","","","","Original global P0-P3 source audit retained","GPL-3.0","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","117.0","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The repo is GPLv3 and should not be used as direct donor code in the HyperTwist core. Its value is in selective behavior and subsystem extraction through a clean-room Model A / Model B process.","Model A inspects the restrictive source; Model B implements only from a scrubbed first-party specification and must not access the repo directly.","Direct incorporation would require GPL-compatible distribution/compliance and is not the planned HyperTwist path.","Yes — preferred path for selectively reproducing stage-specific training and analyzer behavior in first-party code.","high","gpl-clean-room-donor","no","","","","","","","","","","","","","v6.3_final_source_of_truth","Corrected on 2026-04-25 from stale donor posture to dossier-backed focused restrictive clean-room donor status."
|
||||
"yakupbilen/drl-rubiks-cube","https://github.com/yakupbilen/drl-rubiks-cube","HyperTwist","Reserve Bench","Adjacency / future transfer","P2","7482","9237","53.0","117.0","132.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving calibration/detection/state-reconstruction logic while replacing camera UX and integration surfaces.","future candidate","architecture only","Determine whether yakupbilen/drl-rubiks-cube should stay donor/merge-tier for HyperTwist, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","puzzle model, learning flow, UX loops, data schema, replay/export, plugin/hooks","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for algorithm databases, spaced-repetition logic, scramble generation, timer/stat code, virtual cube components, smartcube adapters, and custom-trainer configuration support.","Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.","Integrate as a cubing / algorithm training subsystem for HyperTwist. Preserve the strongest existing pieces — scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition — and expose them behind a portfolio-stable interface. Wire first into tao-yu/Alg-Trainer, then into poliva/cubedex for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer.","Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist.","kkoomen/qbr","foundation + perception donor","Use this repo against the partner as an augmenting layer; preserve the partner as the likely base and mine this repo for capabilities that improve breadth, UX, or specialization.","vivaansinghvi07/rubix-cube-solver","perception + replay donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cubing/cubing.js","state/render backend","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","VectorShell | ScriptoriumAI","VectorShell can borrow spatial/rendering and perception primitives; ScriptoriumAI can borrow tutorial/educational visualization patterns rather than the full engine.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","yakupbilen/drl-rubiks-cube is placed in Reserve Bench for HyperTwist because it best serves the 'Search/training systems bench' role; recommended action is 'future candidate' with repurposing scope 'architecture only'. Confidence is medium because this remains a metadata-level judgment until source audit confirms hidden modules, plugin points, adapters, or architectural strengths.","Useful MIT search and training benchmark for learned-heuristic search, state generation, and experimentation loops, but explicitly below the committed perception and training core.","Audit yakupbilen/drl-rubiks-cube as a vision / perception / AR candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts. Decide whether the best extraction path is moderate modification and whether it belongs as subsystem donor / vision donor. Test the three merger paths in order: 1) kkoomen/qbr [foundation + perception donor]; 2) vivaansinghvi07/rubix-cube-solver [perception + replay donor]; 3) cubing/cubing.js [state/render backend]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_cube_vision_0008","HT_cube_vision","yakupbilen/drl-rubiks-cube","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","117.0","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is aligned with a direct integration path for HyperTwist because it is either already implemented, strategically central, or donor-grade without a visible copyleft constraint in the current materials. Deep incorporation is sensible if the source audit confirms architectural cleanliness.","Direct embed, vendored module, package dependency, or tightly integrated adapter as the architecture requires.","Typically preserve notices, attribution, and license text where required; no special copyleft-driven disclosure posture is normally needed.","Usually unnecessary unless you later decide the existing implementation is too constraining architecturally.","high","strategic-or-implemented-component","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Normalized legacy merge-bench wording to dossier-backed below-core benchmark posture on 2026-04-25."
|
||||
"Hypercubers/hypercubing.xyz","https://github.com/Hypercubers/hypercubing.xyz","HyperTwist","Locked Strategic Donor","Knowledge and curriculum donor","P1","7483","9238","1.0","92.0","101.0","medium","Treat this as a mineable codebase: keep selected internals (algorithms, renderers, adapters, parsers, schedulers) while replacing the surrounding product assumptions and architecture. For this repo class, that usually means preserving generalized puzzle/state/render logic while building a new application shell around it.","repurpose","moderate modification","Determine whether Hypercubers/hypercubing.xyz should stay donor/merge-tier for HyperTwist, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","puzzle model, learning flow, UX loops, data schema, replay/export, plugin/hooks","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for higher-dimensional state/notation representations, projection math, renderer abstractions, puzzle serialization, controls, and replay/training hooks.","Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.","Repurpose selected subsystems rather than the whole product. Mine the repo for nD state model, move notation, renderer, projection controls, solver/traversal logic, puzzle serialization, replay; keep what materially shortens build time, but rebind data contracts, permissions, UI shell, storage, and deployment to the HyperTwist architecture. Best first pairing order: HactarCE/Hyperspeedcube, cubing/cubing.js, tao-yu/Alg-Trainer.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: HactarCE/Hyperspeedcube, cubing/cubing.js, tao-yu/Alg-Trainer.","Repurpose here means: turn it into a higher-dimensional renderer/simulator donor and shared interaction grammar for HyperTwist and long-horizon VectorShell.","HactarCE/Hyperspeedcube","foundation + donor","Use this repo against the partner as an augmenting layer; preserve the partner as the likely base and mine this repo for capabilities that improve breadth, UX, or specialization.","cubing/cubing.js","3D engine + notation/state donor","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","tao-yu/Alg-Trainer","training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","VectorShell | ScriptoriumAI","VectorShell can borrow spatial/rendering and perception primitives; ScriptoriumAI can borrow tutorial/educational visualization patterns rather than the full engine.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep as one of the strongest non-runtime donors in the hypercubing half of HyperTwist; the dossier-backed MIT posture and content value justify promotion above the old donor-bench treatment.","MIT knowledge/curriculum donor with canonical notation, progression, taxonomy, and leaderboard-generation value.","Audit Hypercubers/hypercubing.xyz as a hypercubing / nD engine candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations. Decide whether the best extraction path is heavy modification and whether it belongs as subsystem donor / simulation donor. Test the three merger paths in order: 1) HactarCE/Hyperspeedcube [foundation + donor]; 2) cubing/cubing.js [3D engine + notation/state donor]; 3) tao-yu/Alg-Trainer [training UX donor]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_hyper_engine_0006","HT_hyper_engine","hypercubers/hypercubing.xyz","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","92.0","permissive_or_noncopyleft_known","direct_incorporation_ok","The repo is MIT and is retained as a high-value knowledge and curriculum donor. Direct use of code/content structures is legally straightforward where it materially helps HyperTwist.","Use selectively as a donor for knowledge structures, notation, taxonomy, and leaderboard-generation logic; do not confuse the site snapshot with the canonical repo.","Preserve MIT notices and attribution where required.","Usually unnecessary unless later replacing a narrow implementation seam is cleaner than carrying the upstream code.","high","permissive-knowledge-donor","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Corrected on 2026-04-25 from stale unknown-license donor-bench posture to dossier-backed MIT knowledge/curriculum donor status."
|
||||
"Aarav2709/KubeTimr","https://github.com/Aarav2709/KubeTimr","HyperTwist","Donor Bench","Adjacency / future transfer","P2","7485","9240","2.0","88.0","97.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving cube-state, scramble, scheduling, or timer internals while adapting pedagogy, analytics, and UI.","repurpose","moderate modification","Determine whether Aarav2709/KubeTimr should stay donor/merge-tier for HyperTwist, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","puzzle model, learning flow, UX loops, data schema, replay/export, plugin/hooks","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for algorithm databases, spaced-repetition logic, scramble generation, timer/stat code, virtual cube components, smartcube adapters, and custom-trainer configuration support.","Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.","Repurpose selected subsystems rather than the whole product. Mine the repo for scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition; keep what materially shortens build time, but rebind data contracts, permissions, UI shell, storage, and deployment to the HyperTwist architecture. Best first pairing order: tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer.","Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist.","tao-yu/Alg-Trainer","base + donor swarm","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","poliva/cubedex","specialized training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","Lykos/cube_trainer","sampling/analytics donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","project-local first","Cross-project transfer is possible, but the value is clearest inside the assigned project until source audit exposes more reusable primitives.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Aarav2709/KubeTimr is placed in Donor Bench for HyperTwist because it best serves the 'Focused subsystem donor' role; recommended action is 'repurpose' with repurposing scope 'moderate modification'. Confidence is medium because this remains a metadata-level judgment until source audit confirms hidden modules, plugin points, adapters, or architectural strengths.","Useful subsystem donor for timer-state logic, split-phase handling, local persistence, rolling stats, and keyboard-first offline practice flow.","Audit Aarav2709/KubeTimr as a cubing trainer / solver / timing candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters. Decide whether the best extraction path is moderate modification and whether it belongs as subsystem donor / training donor. Test the three merger paths in order: 1) tao-yu/Alg-Trainer [base + donor swarm]; 2) poliva/cubedex [specialized training UX donor]; 3) Lykos/cube_trainer [sampling/analytics donor]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_training_stack_0015","HT_training_stack","aarav2709/kubetimr","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","88.0","permissive_or_noncopyleft_known","direct_incorporation_ok","This repo is permissively licensed and currently best treated as a focused subsystem donor for timer-state logic, split-phase handling, local persistence, and keyboard-first practice flow. Selective incorporation is legally straightforward, but the product shell should still be reshaped to fit HyperTwist.","Direct embed, vendored module, package dependency, or tightly integrated adapter as the architecture requires.","Typically preserve notices, attribution, and license text where required; no special copyleft-driven disclosure posture is normally needed.","Usually unnecessary unless you later decide the existing implementation is too constraining architecturally.","high","routine-review-only","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Normalized legacy adjacency wording and stale clean-room boundary posture to dossier-backed focused subsystem donor on 2026-04-25."
|
||||
"roice3/MagicTile","https://github.com/roice3/MagicTile","HyperTwist","Locked Strategic Donor","Top-tier non-Euclidean geometry and topology donor","P1","7487","9242","2.0","88.0","97.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving collectors/adapters/runtime topology logic while integrating into a larger control plane.","repurpose","moderate modification","Determine whether roice3/MagicTile should stay donor/merge-tier for HyperTwist, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","puzzle model, learning flow, UX loops, data schema, replay/export, plugin/hooks","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for algorithm databases, spaced-repetition logic, scramble generation, timer/stat code, virtual cube components, smartcube adapters, and custom-trainer configuration support.","Inspect topology/service schema; collectors/agents; auth/integration adapters; caching/state sync; deployment/runtime abstractions; metrics/event correlation; config layering.","Repurpose selected subsystems rather than the whole product. Mine the repo for scramble generation, algorithm database, recognition/training loop, timing/statistics, virtual cube, smartcube hooks, spaced repetition; keep what materially shortens build time, but rebind data contracts, permissions, UI shell, storage, and deployment to the HyperTwist architecture. Best first pairing order: tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: tao-yu/Alg-Trainer, poliva/cubedex, Lykos/cube_trainer.","Repurpose here means: turn it into a trainer engine, solver/timer backend, recognition drill module, or method-specific practice mode for HyperTwist.","project-local anchor","base + donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","shared portfolio utility","augmenter","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cross-project transfer candidate","future merger","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","project-local first","Cross-project transfer is possible, but the value is clearest inside the assigned project until source audit exposes more reusable primitives.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep as a top-tier non-Euclidean geometry and topology donor for HyperTwist; the dossier-backed MIT posture and source richness justify promotion above the old donor-bench treatment.","MIT donor with unusually strong non-Euclidean tiling, topology, and generalized twist infrastructure value.","Audit roice3/MagicTile as a infra / runtime / observability / integration candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect topology/service schema; collectors/agents; auth/integration adapters; caching/state sync; deployment/runtime abstractions; metrics/event correlation; config layering. Decide whether the best extraction path is moderate modification and whether it belongs as subsystem donor / integration utility. Test the three merger paths in order: 1) project-local anchor [base + donor]; 2) shared portfolio utility [augmenter]; 3) cross-project transfer candidate [future merger]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_hyper_engine_0007","HT_hyper_engine","roice3/magictile","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","88.0","permissive_or_noncopyleft_known","direct_incorporation_ok","The repo is MIT and is explicitly retained as a top-tier geometry/topology donor. Direct donor use is legally straightforward if the architecture benefits from it.","Direct donor use or bounded adapter extraction are both acceptable; choose the seam that best preserves the topology and twist infrastructure.","Preserve MIT notices and attribution where required.","Usually unnecessary unless later replacing a narrow seam is cleaner than carrying the upstream code.","high","permissive-top-tier-donor","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Assigned from legacy HY_misc to HT_hyper_engine during cluster normalization on 2026-04-25."
|
||||
"PostHog/posthog","https://github.com/PostHog/posthog","HyperTwist","Donor Bench","Adjacency / future transfer","P2","7492","9247","20.0","72.0","81.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving calibration/detection/state-reconstruction logic while replacing camera UX and integration surfaces.","repurpose","moderate modification","Determine whether PostHog/posthog should stay donor/merge-tier for HyperTwist, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","telemetry and event schemas, replay product boundaries, feature-flag governance, diagnostics, service slices, hidden modules","Inspect package manifests, README/docs, product slices, services, tests, migrations/schemas, and hidden feature flags or experimental modules. Look for replay diagnostics, replay query surfaces, feature-flag governance, activity logs, event schemas, service boundaries, and MIT versus ee/ path splits.","Inspect replay routes and deep links; replay diagnostics; feature-flag CRUD, dependencies, and evaluation; telemetry and event schemas; product and service boundaries; MIT versus ee path splits.","Repurpose selected subsystems rather than the whole product. Mine the repo for telemetry and event schemas, replay diagnostics, replay query surfaces, feature-flag governance, activity logs, and product/service boundary patterns; keep what materially shortens build time, but rebind data contracts, permissions, storage, and deployment to the HyperTwist architecture. Best first pairing order: HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr.","Repurpose here means: turn it into a telemetry spine, replay diagnostics donor, feature-governance donor, or control-plane integration layer.","kkoomen/qbr","foundation + perception donor","Use this repo against the partner as an augmenting layer; preserve the partner as the likely base and mine this repo for capabilities that improve breadth, UX, or specialization.","vivaansinghvi07/rubix-cube-solver","perception + replay donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cubing/cubing.js","state/render backend","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","VectorShell | ScriptoriumAI","VectorShell can borrow spatial/rendering and perception primitives; ScriptoriumAI can borrow tutorial/educational visualization patterns rather than the full engine.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","PostHog/posthog is placed in Donor Bench for HyperTwist because it best serves the 'Telemetry / replay / feature-governance donor' role; recommended action remains 'repurpose' with repurposing scope 'moderate modification'. Its real retained value is replay diagnostics, flag governance, event-schema thinking, and service-boundary patterns rather than any vision or perception role.","Useful subsystem donor for HyperTwist in telemetry, replay diagnostics, feature flags, event-schema design, and vertical-slice control-plane patterns rather than the core runtime or product shell.","Audit PostHog/posthog as a telemetry / replay / feature-governance candidate for HyperTwist. Do not stop at README-level features. Inspect: replay routes and deep links, replay diagnostics, feature-flag CRUD/dependencies/evaluation, telemetry and event schemas, product/service boundaries, and MIT versus ee/ path splits. Decide whether the best extraction path remains moderate modification and which seams should stay bounded due mixed licensing or mission misfit. Return hidden modules, reusable schemas, protocol layers, plugin hooks, replay/debugging surfaces, and any subsystem stronger than the visible product shell.","HT_control_plane_0001","HT_control_plane","posthog/posthog","","","","","","","Original global P0-P3 source audit retained","MIT outside ee/; enterprise-restricted in ee/","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","72.0","mixed_or_boundary_sensitive_known","bounded_sidecar_or_selective_reimplementation","The repo is mixed-license: MIT outside ee/ and enterprise-restricted inside ee/. Use only clearly MIT paths as bounded telemetry, replay, and feature-governance donor material, and exclude or reimplement enterprise-gated paths.","Use only clearly MIT paths outside ee/ as bounded telemetry, replay, and feature-governance donor surfaces; exclude enterprise paths or reimplement equivalent seams.","Keep MIT notices for reused paths and do not incorporate ee/ without separate commercial rights; verify path provenance before shipping.","Sometimes useful for enterprise-gated or off-mission slices, but not required for clearly MIT paths.","high","mixed-license-path-review-required","no","","","","","","","","","","","","","v6.3_final_source_of_truth","Assigned to HT_control_plane and normalized telemetry/replay/feature-governance wording on 2026-04-25."
|
||||
"HactarCE/2x2x2x2-Scrambler","https://github.com/HactarCE/2x2x2x2-Scrambler","HyperTwist","Donor Bench","Focused restrictive clean-room donor target","P2","7496","9251","2.0","63.0","63.0","low-to-medium","Architecture only. Treat HactarCE/2x2x2x2-Scrambler as a design and subsystem reference first; source audit should look for transplantable patterns, adapters, data contracts, pipeline ideas, or UI/control abstractions before any decision to operationalize.","repurpose","architecture only","Determine the real reusable value of HactarCE/2x2x2x2-Scrambler for HyperTwist and decide whether it should be promoted, retained, or demoted in the v6 corpus.","Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.","Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.","Inspect state representations, move/alg parsers, scrambler generators, geometry/math cores, renderer abstractions, engine bindings, and XR/web surfaces.","Primary realization path: use as a simulation, training, renderer, binding, or integration donor inside HyperTwist's dual stack of physical-cube analysis and higher-dimensional virtual training.","Consolidate by HyperTwist layer: core puzzle logic, scramblers/algs, renderer/bindings, XR/game-engine surfaces, experiments/comparators.","Repurpose toward renderer abstractions, puzzle-logic libraries, solver bindings, training UIs, or XR/engine adapters.","HactarCE/Hyperspeedcube","foundation repo + feature donor","Use HactarCE/2x2x2x2-Scrambler as a HyperTwist donor into HactarCE/Hyperspeedcube for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","cubing/cubing.js","engine repo + interface donor","Use HactarCE/2x2x2x2-Scrambler as a HyperTwist donor into cubing/cubing.js for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","kkoomen/qbr","feature extraction only","Use HactarCE/2x2x2x2-Scrambler as a HyperTwist donor into kkoomen/qbr for puzzle logic, bindings, renderer ideas, or training/runtime augmentation.","multi-project","Audit for hidden abstractions that travel across projects.","Source reveals a strong reusable subsystem, extensibility layer, protocol boundary, renderer core, data model, or automation surface that clearly strengthens one of the project stacks.","Source reveals the repo is mostly documentation, thin wrappers, packaging glue, stale scaffolding, or a weak duplicate with no meaningful transplantable subsystem.","Source-audit note, role recommendation, hidden-value extraction, exact integration path, and reclassification decision.","Implemented capability; hidden reusable modules; strongest integration path; strongest merger path; upgrade triggers; downgrade triggers; final recommended bucket.","Use v6 unified board + P2 tier packet + project design language + relevant family references.","Keep as a narrow but real clean-room donor for Melinda 2x2x2x2 state encoding, handedness/parity repair, random-state generation, move-family representation, and flat debug/teaching views.","GPL scrambler with copied-port lineage notes; valuable only through restrictive clean-room extraction, not donor use.","Inspect HactarCE/2x2x2x2-Scrambler directly in source. Do not dismiss for license. Preserve nuanced distinctions between donor, reserve, comparator, and exclusion.","HT_cube_semantics_0004","HT_cube_semantics","hactarce/2x2x2x2-scrambler","supplemental_v6_not_runtime_anchored","","","","","no","v6_unified_source_of_truth_pack","GPL-3.0","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","","","2","3","63.0","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The repo is GPL-3.0 and the source explicitly notes a ported lineage from an earlier scrambler. Retain it only as a focused clean-room donor target and implement any valuable behavior through a scrubbed first-party specification.","Model A may inspect the restrictive source; Model B should implement only from a scrubbed first-party specification.","Direct incorporation would require GPL-compatible distribution/compliance and is not the planned HyperTwist path.","Yes — this is the preferred path for reproducing the 2x2x2x2 scrambler/state behaviors in first-party code.","high","gpl-clean-room-donor","no","","","","","","","","","","","","","v6.3_final_source_of_truth","Assigned to HT_cube_semantics during cluster normalization on 2026-04-25."
|
||||
"SYSTRAN/faster-whisper","https://github.com/SYSTRAN/faster-whisper","multi-project","Donor Bench","Cross-project / future-adjacent","P2","8351","10345","49.0","71.0","80.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving parsers/graph schema/indexing while swapping layout, storage, or UX layers.","repurpose","moderate modification","Determine whether SYSTRAN/faster-whisper should stay donor/merge-tier for multi-project, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","STT API surface, VAD chunking, batch inference, timestamps, service boundaries, model/runtime constraints, hidden modules","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, benchmark scripts, and hidden experimental modules. Look for VAD, batch inference, timestamps, hotwords, model/runtime constraints, and service-layer boundaries.","Inspect transcription API and dataclasses; batched inference; VAD chunking; word timestamps; hotwords and prefix conditioning; service-layer boundaries; benchmark and test coverage.","Repurpose selected subsystems rather than the whole product. Mine the repo for VAD-aware segmentation, batch transcription, timestamps, hotword and prefix conditioning, and Python service ergonomics; keep what materially shortens build time, but rebind data contracts, permissions, storage, and deployment to the target architecture. Best first pairing order: ggml-org/whisper.cpp, rhasspy/piper, coqui-ai/TTS.","Consolidate under the project-specific anchor stack, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: sentrux/sentrux, HactarCE/Hyperspeedcube, outline/outline.","Repurpose here means: turn it into a Python STT service, timestamped speech pipeline, or batch transcription donor.","project-local anchor","base + donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","shared portfolio utility","augmenter","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cross-project transfer candidate","future merger","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","project-local first","Cross-project transfer is possible, but the value is clearest inside the assigned project until source audit exposes more reusable primitives.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","SYSTRAN/faster-whisper is placed in Donor Bench for multi-project because it provides the clearest Python STT service-layer path in the voice stack. Recommended action remains repurpose, but the real retained value is batch transcription, VAD-aware chunking, timestamps, and Python-side service integration rather than any code-intelligence or graph role.","Useful subsystem donor for multi-project, primarily in the 'Cross-project / future-adjacent' role; strongest current Python STT donor and service-layer candidate in the voice stack.","Audit SYSTRAN/faster-whisper as a voice / multimodal I/O candidate for multi-project. Do not stop at README-level features. Inspect: transcription API and dataclasses, batched inference, VAD chunking, word timestamps, hotwords and prefix conditioning, service-layer boundaries, and benchmark/test coverage. Decide whether it should remain the primary Python STT donor and what should stay behind a bounded Python service seam. Test the three merger paths in order: 1) project-local anchor [base + donor]; 2) shared portfolio utility [augmenter]; 3) cross-project transfer candidate [future merger]. Return hidden modules, reusable schemas, protocol layers, runtime boundaries, tests/benchmarks, and any subsystem stronger than the visible shell.","MU_misc_0001","MU_misc","systran/faster-whisper","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Potentially relevant","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","4","3","71.0","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded Python STT donor/service candidate; review chosen model checkpoints separately, but no clean-room path is required by default.","Use directly as a bounded Python STT service or adapter layer; keep model/runtime selection and deployment behind a speech-input seam.","Typically preserve notices, attribution, and license text where required; review selected model checkpoints separately from the code license.","Usually unnecessary unless you later decide to replace a narrow hot path or remove Python/CTranslate2 dependencies.","high","model-artifact-review-required","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Merged v6.1 copyleft layer and v6.2 SRE layer; use v6.3 docs + workbook as canonical handoff."
|
||||
"coqui-ai/TTS","https://github.com/coqui-ai/TTS","multi-project","Donor Bench","Cross-project / future-adjacent","P2","8352","10346","49.0","71.0","80.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving streaming/audio pipeline logic while adapting commands, wake flows, and assistant integration.","repurpose","moderate modification","Determine whether coqui-ai/TTS should stay donor/merge-tier for multi-project, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","API surface, synthesis orchestration, multilingual and speaker handling, voice conversion, model registry, deployment boundary, hidden modules","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, model registry files, and hidden experimental modules. Look for synthesis orchestration, sentence splitting, multilingual and speaker handling, voice conversion, server deployment patterns, and model-license metadata.","Inspect public API, synthesis and orchestration spine, server boundary, multilingual and speaker handling, XTTS path, model registry and license metadata, and optional voice conversion.","Repurpose selected subsystems rather than the whole product. Mine the repo for synthesis orchestration, multilingual and speaker handling, local service wrappers, voice-conversion paths, and model-registry/license handling; keep what materially shortens build time, but rebind data contracts, permissions, storage, and deployment to the target architecture. Best first pairing order: rhasspy/piper, ggml-org/whisper.cpp, SYSTRAN/faster-whisper.","Consolidate under the project-specific anchor stack, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: sentrux/sentrux, HactarCE/Hyperspeedcube, outline/outline.","Repurpose here means: turn it into a bounded voice-service seam, coach narration donor, or multilingual TTS and cloning donor.","project-local anchor","base + donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","shared portfolio utility","augmenter","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cross-project transfer candidate","future merger","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","VectorShell | HyperTwist | ScriptoriumAI","This capability is broadly portable across the portfolio because interaction, orchestration, and shell/UI patterns can be shared with thin domain adapters.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","coqui-ai/TTS is placed in Donor Bench for multi-project because it provides the richest current voice-output and coaching architecture in the stack. Recommended action remains repurpose, but the real retained value is synthesis orchestration, multilingual and speaker handling, XTTS/voice-conversion paths, and model-registry discipline rather than broad assistant scope.","Useful subsystem donor for multi-project, primarily in the 'Cross-project / future-adjacent' role; strongest current voice and coaching donor, but boundary-sensitive because code and model payload licensing must be separated.","Audit coqui-ai/TTS as a voice / multimodal I/O candidate for multi-project. Do not stop at README-level features. Inspect: public API surface, synthesis/orchestration spine, server boundary, multilingual and speaker handling, XTTS path, model registry and license metadata, and optional voice conversion. Decide whether it should remain the strongest voice/coaching donor and what should stay behind a bounded voice-service seam. Test the three merger paths in order: 1) project-local anchor [base + donor]; 2) shared portfolio utility [augmenter]; 3) cross-project transfer candidate [future merger]. Return hidden modules, reusable schemas, protocol layers, runtime boundaries, tests/fixtures, and any subsystem stronger than the visible shell.","MU_misc_0002","MU_misc","coqui-ai/tts","","","","","","","Original global P0-P3 source audit retained","MPL-2.0 code; mixed model payload licenses","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Potentially relevant","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","4","3","71.0","mixed_or_boundary_sensitive_known","bounded_sidecar_or_selective_reimplementation","Code is usable under MPL-2.0, but selected model weights carry mixed per-model licenses and some require separate terms. Keep the repo behind a bounded voice-service seam and decide model adoption case by case rather than treating it as a blanket permissive dependency.","Use the code behind a bounded voice-service seam; select model weights individually and keep model-license decisions separate from code adoption.","Preserve MPL notices and file-level obligations where applicable, and review each chosen model license or ToS separately before shipping.","Sometimes useful only if you later need a fully proprietary embedded voice stack or want to avoid model-license entanglement; not the default path.","medium","model-license-selection-required","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Merged v6.1 copyleft layer and v6.2 SRE layer; use v6.3 docs + workbook as canonical handoff."
|
||||
"ggml-org/whisper.cpp","https://github.com/ggml-org/whisper.cpp","multi-project","Donor Bench","Cross-project / future-adjacent","P2","8353","10347","49.0","71.0","80.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving streaming/audio pipeline logic while adapting commands, wake flows, and assistant integration.","repurpose","moderate modification","Determine whether ggml-org/whisper.cpp should stay donor/merge-tier for multi-project, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","native STT runtime seam, VAD, grammar-constrained decoding, server boundary, portability, hidden modules","Inspect package manifests, README/docs, src/include tree, examples, tests, CI workflows, build configs, model tooling, and hidden experimental modules. Look for VAD, grammar support, streaming/segmentation, server boundaries, device/runtime abstraction, and performance shortcuts.","Inspect C/C++ API surface; VAD path; grammar-constrained decoding; server/runtime examples; model loading and portability seams; tests and benchmarks.","Repurpose selected subsystems rather than the whole product. Mine the repo for native STT runtime seams, VAD, grammar-constrained decoding, segmented speech capture, and server-side deployment patterns; keep what materially shortens build time, but rebind data contracts, permissions, storage, and deployment to the target architecture. Best first pairing order: SYSTRAN/faster-whisper, rhasspy/piper, coqui-ai/TTS.","Consolidate under the project-specific anchor stack, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: sentrux/sentrux, HactarCE/Hyperspeedcube, outline/outline.","Repurpose here means: turn it into an offline STT sidecar, grammar-constrained command surface, or native speech-input donor.","project-local anchor","base + donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","shared portfolio utility","augmenter","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cross-project transfer candidate","future merger","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","VectorShell | HyperTwist | ScriptoriumAI","This capability is broadly portable across the portfolio because interaction, orchestration, and shell/UI patterns can be shared with thin domain adapters.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","ggml-org/whisper.cpp is placed in Donor Bench for multi-project because it is the clearest native/offline STT anchor in the voice stack. Recommended action remains repurpose, but the real retained value is a bounded speech-input runtime, VAD, grammar-constrained decoding, and portable deployment rather than a full product shell.","Useful subsystem donor for multi-project, primarily in the 'Cross-project / future-adjacent' role; strongest current native/offline STT sidecar candidate in the voice stack.","Audit ggml-org/whisper.cpp as a voice / multimodal I/O candidate for multi-project. Do not stop at README-level features. Inspect: C/C++ API surface, VAD, grammar-constrained decoding, server/runtime examples, model loading and portability seams, and benchmark/test coverage. Decide whether it should remain the primary offline STT sidecar candidate and what should stay behind a bounded native seam. Test the three merger paths in order: 1) project-local anchor [base + donor]; 2) shared portfolio utility [augmenter]; 3) cross-project transfer candidate [future merger]. Return hidden modules, reusable schemas, protocol layers, runtime boundaries, tests/benchmarks, and any subsystem stronger than the visible shell.","MU_misc_0003","MU_misc","ggml-org/whisper.cpp","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Potentially relevant","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","4","3","71.0","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. This repo is best used as a bounded offline STT sidecar or native speech-input seam; no clean-room path is required by default.","Use directly as a bounded native STT sidecar or library adapter; keep grammar, VAD, and model/runtime choices behind a speech-input seam.","Typically preserve notices, attribution, and license text where required; review selected model files or distributions separately from the code license.","Usually unnecessary unless you later choose to replace a narrow hot path or fully internalize the runtime.","high","model-artifact-review-recommended","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Merged v6.1 copyleft layer and v6.2 SRE layer; use v6.3 docs + workbook as canonical handoff."
|
||||
"rhasspy/piper","https://github.com/rhasspy/piper","multi-project","Donor Bench","Cross-project / future-adjacent","P2","8354","10348","49.0","71.0","80.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving streaming/audio pipeline logic while adapting commands, wake flows, and assistant integration.","repurpose","moderate modification","Determine whether rhasspy/piper should stay donor/merge-tier for multi-project, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","local TTS runtime seam, ONNX and eSpeak integration, streaming output, HTTP service boundary, voice catalog, hidden modules","Inspect package manifests, README/docs, src tree, examples, tests, build configs, voice catalog files, and hidden runtime switches. Look for ONNX runtime integration, phonemization, lightweight service boundaries, audio streaming, voice acquisition, and deployment constraints.","Inspect C++ runtime core; voice loading and download path; streaming output; HTTP service boundary; speaker and phonemization config; selected voice artifact constraints.","Repurpose selected subsystems rather than the whole product. Mine the repo for lean local TTS runtime, HTTP wrapping, voice loading and download logic, streaming WAV and raw output, and ONNX/eSpeak integration; keep what materially shortens build time, but rebind data contracts, permissions, storage, and deployment to the target architecture. Best first pairing order: coqui-ai/TTS, ggml-org/whisper.cpp, SYSTRAN/faster-whisper.","Consolidate under the project-specific anchor stack, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: sentrux/sentrux, HactarCE/Hyperspeedcube, outline/outline.","Repurpose here means: turn it into a lean offline TTS sidecar or direct local narration donor.","project-local anchor","base + donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","shared portfolio utility","augmenter","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cross-project transfer candidate","future merger","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","VectorShell | HyperTwist | ScriptoriumAI","This capability is broadly portable across the portfolio because interaction, orchestration, and shell/UI patterns can be shared with thin domain adapters.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
|
||||
2) Hidden capabilities found only in source
|
||||
3) Best salvageable modules/files/packages
|
||||
4) Integration path into target project
|
||||
5) Repurpose path outside the original thesis
|
||||
6) Best merge partners and exact coupling seam
|
||||
7) Reasons to promote / retain / demote
|
||||
8) Confidence change after source audit
|
||||
9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","rhasspy/piper is placed in Donor Bench for multi-project because it provides the leanest current local TTS runtime seam in the voice stack. Recommended action remains repurpose, but the real retained value is ONNX and eSpeak runtime simplicity, streaming output, and deployable local HTTP wrapping rather than broad voice-platform scope.","Useful subsystem donor for multi-project, primarily in the 'Cross-project / future-adjacent' role; lean direct local TTS sidecar candidate.","Audit rhasspy/piper as a voice / multimodal I/O candidate for multi-project. Do not stop at README-level features. Inspect: C++ runtime core, voice loading and download path, streaming output, HTTP service boundary, speaker and phonemization config, and selected voice artifact constraints. Decide whether it should remain the lean direct local TTS sidecar candidate and what should stay behind a bounded local voice seam. Test the three merger paths in order: 1) project-local anchor [base + donor]; 2) shared portfolio utility [augmenter]; 3) cross-project transfer candidate [future merger]. Return hidden modules, reusable schemas, protocol layers, runtime boundaries, tests/fixtures, and any subsystem stronger than the visible shell.","MU_misc_0004","MU_misc","rhasspy/piper","","","","","","","Original global P0-P3 source audit retained","MIT code; voice artifacts reviewed separately","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Potentially relevant","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","4","3","71.0","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. The real review point is selected voice artifacts, not the runtime code; keep voice selection separate from code adoption.","Use directly as a bounded local TTS sidecar or simple HTTP service; keep selected voice artifacts under separate review.","Typically preserve notices, attribution, and license text where required; review chosen voices or model cards separately from the code license.","Usually unnecessary unless you later replace the runtime for packaging or architecture reasons.","high","voice-artifact-review-required","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Merged v6.1 copyleft layer and v6.2 SRE layer; use v6.3 docs + workbook as canonical handoff."
|
||||
"met4citizen/TalkingHead","https://github.com/met4citizen/TalkingHead","HyperTwist","Donor Bench","Browser embodied coach surface","P2","","","","","","medium","Retain the reusable avatar, lip-sync, and retargeting layers, but replace the demo shell, asset assumptions, and voice-service integration with HyperTwist-owned surfaces.","repurpose","moderate modification","Determine whether TalkingHead should remain the primary embodied coach donor and which runtime seams should stay bounded.","avatar runtime, lip-sync queueing, streamed speech, subtitle timing, avatarOnly embedding, retargeting","Inspect modules, examples, tests, site config, streaming demos, retargeter, and playback worklet code. Look for embodied-coach embedding, lip-sync, subtitle timing, gesture and expression surfaces, and asset assumptions.","Inspect talkinghead runtime; speech queueing and streaming; viseme and blendshape flow; avatarOnly embedding; retargeting; and audio worklet behavior.","Repurpose selected subsystems rather than the whole product. Mine the repo for embodied coach avatar runtime, lip-sync and subtitle timing, avatar-only embedding, retargeting, and streamed speech playback; keep what shortens build time, but rebind assets, voice services, and UI shell to the HyperTwist architecture.","","Repurpose here means: turn it into a browser-side embodied coach or companion layer.","","","","","","","","","","","","Upgrade if source reveals unusually reusable browser-runtime seams, clean adapter boundaries, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos in the same lane.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed browser/XR capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended pairing or dependency posture; 5) Risks or licensing notes.","Primary: HT_browser_surface cluster packet plus the repo-specific Markdown dossier. Optional: companion browser/XR rows in the same cluster.","met4citizen/TalkingHead is placed in Donor Bench for HyperTwist because it provides embodied coach UI, streaming lip-sync, retargeting, and avatar-only embedding behavior. Recommended action remains repurpose, but the retained value is a bounded browser coach surface rather than a general avatar product.","Useful subsystem donor for HyperTwist, primarily in the browser companion layer; strongest embodied coach and avatar presentation donor in the current stack.","Audit met4citizen/TalkingHead as a browser embodied-coach candidate for HyperTwist. Inspect the avatar runtime, streaming lip-sync, subtitle timing, avatarOnly embedding, retargeting, and audio worklet behavior. Decide which seams can be used directly and which must remain bounded behind the HyperTwist coaching shell.","HT_browser_surface_0001","HT_browser_surface","met4citizen/talkinghead","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser-side donor for embodied coach presentation rather than as a product shell.","Use directly as a bounded browser-side dependency or adapter layer; keep voice services, product logic, and asset provenance outside the upstream shell.","Typically preserve notices, attribution, and license text where required; review sample avatars or media separately from the code license.","Usually unnecessary unless you later replace a narrow upstream layer for product-shaping reasons.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-24."
|
||||
"apache/echarts","https://github.com/apache/echarts","HyperTwist","Donor Bench","Browser analytics and reporting surface","P2","","","","","","medium","Retain the reusable chart runtime and reporting patterns, but keep HyperTwist domain schemas, page shell, and training logic outside the upstream system.","repurpose","moderate modification","Determine whether echarts should remain the primary browser analytics and reporting donor for HyperTwist companion surfaces.","option manager, datastore, zoom and history, thumbnail and export, SSR, chart modularity","Inspect manifests, README/docs, src core, model, data, component, export, and SSR folders. Look for modular chart runtime, data-store abstractions, export surfaces, and reporting-specific UI behavior.","Inspect OptionManager, DataStore, zoom and history behavior, thumbnail and export features, SSR and hydration seams, and accessibility surface.","Repurpose selected subsystems rather than the whole product. Mine the repo for chart runtime, option and data-store patterns, export and save-as-image behavior, zoom and history handling, and SSR reporting surfaces; keep what shortens build time, but rebind analytics schemas and application shell to the HyperTwist architecture.","","Repurpose here means: turn it into a bounded browser analytics and reporting layer for dashboards, replay summaries, and coaching views.","","","","","","","","","","","","Upgrade if source reveals unusually reusable browser-runtime seams, clean adapter boundaries, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos in the same lane.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed browser/XR capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended pairing or dependency posture; 5) Risks or licensing notes.","Primary: HT_browser_surface cluster packet plus the repo-specific Markdown dossier. Optional: companion browser/XR rows in the same cluster.","apache/echarts is placed in Donor Bench for HyperTwist because it provides the strongest current browser analytics and reporting stack with SSR, export, and serious data-store behavior. Recommended action remains repurpose, but the retained value is bounded reporting and coaching analytics rather than a product shell.","Useful subsystem donor for HyperTwist, primarily in the browser companion layer; strongest current analytics and reporting donor in the browser stack.","Audit apache/echarts as a browser analytics and reporting candidate for HyperTwist. Inspect the modular chart runtime, OptionManager and DataStore, export surfaces, zoom and history behavior, SSR path, and accessibility seams. Decide which parts should remain direct dependencies versus concept-only references.","HT_browser_surface_0002","HT_browser_surface","apache/echarts","","","","","","","","Apache-2.0","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is Apache-2.0 and direct use is allowed. Treat it as a bounded reporting and analytics donor.","Use directly as a bounded browser analytics dependency; keep HyperTwist data contracts and product logic outside the upstream shell.","Preserve LICENSE and NOTICE materials where required and review redistributed assets separately from the code license.","Usually unnecessary unless you later replace a narrow upstream layer for product-shaping reasons.","high","notice-file-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-24."
|
||||
"ecomfe/echarts-gl","https://github.com/ecomfe/echarts-gl","HyperTwist","Merge Bench","Browser 3D analytics and explainer surface","P3","","","","","","medium","Retain selective 3D analytics surfaces, but keep HyperTwist domain models, scene ownership, and broader product shell outside the upstream package.","integrate","moderate modification","Determine whether echarts-gl should remain the bounded 3D analytics extension beneath echarts and what should stay outside HyperTwist core.","3D chart exports, GL layer mounting, graph and flow surfaces, view helper behavior, interaction model","Inspect manifests, README/docs, src chart and component exports, GL helper modules, and integration points with echarts and zrender.","Inspect 3D and GL chart exports, GL layer mounting, graph and flow surfaces, view helper behavior, and chart-space interaction handling.","Integrate selected subsystems rather than the whole product. Mine the repo for 3D analytics and explainer surfaces, GL layer mounting, and view helper behavior; keep what shortens build time, but bind it to HyperTwist analytics schemas and browser companion UI.","","Integrate here means: merge bounded 3D analytics and explainer surfaces into the browser reporting stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable browser-runtime seams, clean adapter boundaries, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos in the same lane.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed browser/XR capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended pairing or dependency posture; 5) Risks or licensing notes.","Primary: HT_browser_surface cluster packet plus the repo-specific Markdown dossier. Optional: companion browser/XR rows in the same cluster.","ecomfe/echarts-gl is placed in Merge Bench for HyperTwist because it adds bounded 3D analytics and explainer value on top of echarts. Recommended action remains integrate, but the retained value is selective 3D reporting and graph surface behavior rather than a product runtime.","Useful merge candidate for HyperTwist, primarily in the browser companion layer; strongest value sits in 3D chart and GL explainer surfaces beneath the echarts lane.","Audit ecomfe/echarts-gl as a browser 3D analytics companion to apache/echarts. Inspect the 3D chart exports, GL view handling, and interaction seams. Decide which pieces deserve direct dependency use versus conceptual guidance only.","HT_browser_surface_0003","HT_browser_surface","ecomfe/echarts-gl","","","","","","","","BSD-3-Clause","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is BSD-3-Clause and direct use is allowed. Treat it as a bounded 3D analytics extension rather than a runtime foundation.","Use directly as a bounded browser-side dependency beneath the reporting stack; keep HyperTwist scene ownership and product logic outside the upstream shell.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless you later replace a narrow upstream layer for product-shaping reasons.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-24."
|
||||
"KhronosGroup/glTF-Sample-Viewer","https://github.com/KhronosGroup/glTF-Sample-Viewer","HyperTwist","Donor Bench","Browser asset validation and viewer surface","P3","","","","","","medium","Retain the useful asset-validation and viewer surfaces, but keep HyperTwist asset flows, editor shell, and product logic outside the upstream viewer.","repurpose","moderate modification","Determine whether glTF-Sample-Viewer should remain the primary standards-validation viewer donor for browser asset tooling.","validator integration, material variants, environment controls, capture flow, renderer handoff, viewer shell","Inspect manifests, README/docs, src main and UI logic, bundled renderer submodule, and validation-related surfaces.","Inspect validator integration, material-variant support, environment and tone-mapping controls, capture behavior, and the relationship to glTF-Sample-Renderer.","Repurpose selected subsystems rather than the whole product. Mine the repo for standards-aware asset preview, validation, capture, environment control, and viewer-shell behavior; keep what shortens build time, but bind it to HyperTwist asset tooling and browser companion surfaces.","","Repurpose here means: turn it into a bounded asset-validation and preview donor for browser tooling.","","","","","","","","","","","","Upgrade if source reveals unusually reusable browser-runtime seams, clean adapter boundaries, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos in the same lane.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed browser/XR capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended pairing or dependency posture; 5) Risks or licensing notes.","Primary: HT_browser_surface cluster packet plus the repo-specific Markdown dossier. Optional: companion browser/XR rows in the same cluster.","KhronosGroup/glTF-Sample-Viewer is placed in Donor Bench for HyperTwist because it provides standards-aware asset validation, inspection, and viewer behavior. Recommended action remains repurpose, but the retained value is bounded asset QA and preview tooling rather than gameplay or runtime ownership.","Useful subsystem donor for HyperTwist, primarily in the browser companion layer; strongest value sits in official glTF standards validation and inspection tooling.","Audit KhronosGroup/glTF-Sample-Viewer as a browser asset-validation and inspection candidate for HyperTwist. Inspect validator integration, capture flow, material variants, environment controls, and the renderer handoff. Decide which surfaces deserve direct use or selective extraction.","HT_browser_surface_0004","HT_browser_surface","khronosgroup/gltf-sample-viewer","","","","","","","","Apache-2.0","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is Apache-2.0 and direct use is allowed. Treat it as a bounded standards-viewer and asset-QA donor.","Use directly as a bounded asset-validation dependency or sidecar; keep HyperTwist asset workflows and product logic outside the upstream viewer shell.","Preserve LICENSE and NOTICE materials where required.","Usually unnecessary unless you later replace a narrow upstream layer for product-shaping reasons.","high","notice-file-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-24."
|
||||
"google/model-viewer","https://github.com/google/model-viewer","HyperTwist","Donor Bench","Browser 3D presentation and inspection surface","P2","","","","","","medium","Retain the useful browser presentation and inspection layers, but keep HyperTwist product logic, page shell, and owned runtime direction outside the upstream project.","repurpose","moderate modification","Determine whether model-viewer should remain the primary browser presentation and inspection donor for HyperTwist companion surfaces.","custom element runtime, annotations, AR and controls, scene graph access, space-opera/editor package, render fidelity tools","Inspect manifests, README/docs, packages/model-viewer runtime, space-opera, render-fidelity-tools, model-viewer-effects, and docs/example surfaces.","Inspect model-viewer runtime mixins, annotation and AR behavior, scene-graph access, space-opera editor surfaces, and render-fidelity support.","Repurpose selected subsystems rather than the whole product. Mine the repo for browser 3D presentation, annotations, inspection, snippet and export behavior, hotspot editing, and fidelity tooling; keep what shortens build time, but bind it to HyperTwist browser companion surfaces and asset workflows.","","Repurpose here means: turn it into a bounded browser 3D presentation, inspection, and editor donor.","","","","","","","","","","","","Upgrade if source reveals unusually reusable browser-runtime seams, clean adapter boundaries, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos in the same lane.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed browser/XR capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended pairing or dependency posture; 5) Risks or licensing notes.","Primary: HT_browser_surface cluster packet plus the repo-specific Markdown dossier. Optional: companion browser/XR rows in the same cluster.","google/model-viewer is placed in Donor Bench for HyperTwist because it provides the strongest current browser 3D presentation and inspection stack, plus bundled editor and fidelity packages. Recommended action remains repurpose, but the retained value is bounded web preview, inspection, and AR-friendly presentation rather than a gameplay runtime.","Useful subsystem donor for HyperTwist, primarily in the browser companion layer; strongest current browser 3D presentation and inspection donor in the stack.","Audit google/model-viewer as a browser 3D presentation and inspection candidate for HyperTwist. Inspect the custom element runtime, annotation and AR behavior, scene-graph access, bundled editor and fidelity packages, and docs/demo tooling. Decide which surfaces merit direct use versus selective extraction.","HT_browser_surface_0005","HT_browser_surface","google/model-viewer","","","","","","","","Apache-2.0","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is Apache-2.0 and direct use is allowed. Treat it as a bounded browser presentation and inspection donor.","Use directly as a bounded browser-side dependency or adapter layer; keep HyperTwist runtime ownership, asset workflows, and product logic outside the upstream shell.","Preserve LICENSE and NOTICE materials where required and review bundled assets separately from the code license.","Usually unnecessary unless you later replace a narrow upstream layer for product-shaping reasons.","high","notice-file-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-24."
|
||||
"mrdoob/three.js","https://github.com/mrdoob/three.js","HyperTwist","Donor Bench","Browser 3D substrate","P2","","","","","","medium","Retain it mainly as a dependency substrate. Do not treat it as the owned gameplay foundation or let it reshape the Unreal-first runtime direction.","repurpose","moderate modification","Determine whether three.js should remain the default browser 3D substrate beneath HyperTwist companion surfaces.","renderer, scene, camera, math core, loaders, WebXR manager, addons, editor","Inspect manifests, README/docs, src core and renderer folders, WebXR manager, addons, examples references, and editor shell.","Inspect core renderer and scene stack, loaders and exporters, WebXR manager, addons surface, and editor shell.","Repurpose selected subsystems rather than the whole product. Mine the repo for the browser 3D substrate, loader and exporter behavior, WebXR runtime hooks, and utility layers; keep what shortens build time, but leave HyperTwist gameplay and owned runtime direction outside the upstream engine.","","Repurpose here means: use it as the bounded browser-side 3D substrate and keep HyperTwist product logic above it.","","","","","","","","","","","","Upgrade if source reveals unusually reusable browser-runtime seams, clean adapter boundaries, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos in the same lane.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed browser/XR capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended pairing or dependency posture; 5) Risks or licensing notes.","Primary: HT_browser_surface cluster packet plus the repo-specific Markdown dossier. Optional: companion browser/XR rows in the same cluster.","mrdoob/three.js is placed in Donor Bench for HyperTwist because it is the core browser 3D substrate beneath the newer viewer, XR, and companion-surface repos. Recommended action remains repurpose, but the retained value is a bounded browser dependency layer rather than product differentiation.","Useful subsystem donor for HyperTwist, primarily in the browser companion layer; strongest commodity browser 3D substrate in the current stack.","Audit mrdoob/three.js as the browser 3D substrate beneath HyperTwist companion surfaces. Inspect renderer, scene, camera, math, loader, WebXR, and editor behavior. Decide what should be used directly as dependency substrate versus what should remain conceptual.","HT_browser_surface_0006","HT_browser_surface","mrdoob/three.js","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser 3D substrate rather than as an owned runtime foundation.","Use directly as a bounded browser-side dependency; keep HyperTwist gameplay, puzzle logic, and owned runtime direction outside the upstream engine.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless you later replace a narrow upstream layer for product-shaping reasons.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-24."
|
||||
"pmndrs/postprocessing","https://github.com/pmndrs/postprocessing","HyperTwist","Merge Bench","Browser post-processing substrate","P3","","","","","","medium","Retain selective effect infrastructure, but keep HyperTwist scene ownership, domain logic, and product shell outside the upstream package.","integrate","moderate modification","Determine whether postprocessing should remain the bounded browser effect-composer substrate beneath the companion stack.","EffectComposer, EffectPass, outline, SSAO, effect catalog, performance assumptions","Inspect manifests, README/docs, core composer and pass code, major effects, and integration seams with three.js.","Inspect EffectComposer and EffectPass, outline and SSAO effect behavior, effect catalog breadth, and performance assumptions.","Integrate selected subsystems rather than the whole product. Mine the repo for effect-composer, outline, SSAO, and bounded browser emphasis behavior; keep what shortens build time, but bind it to HyperTwist browser viewers and coach surfaces.","","Integrate here means: merge bounded browser-side effect and emphasis infrastructure into the companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable browser-runtime seams, clean adapter boundaries, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos in the same lane.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed browser/XR capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended pairing or dependency posture; 5) Risks or licensing notes.","Primary: HT_browser_surface cluster packet plus the repo-specific Markdown dossier. Optional: companion browser/XR rows in the same cluster.","pmndrs/postprocessing is placed in Merge Bench for HyperTwist because it provides bounded browser post-processing infrastructure beneath three.js-based viewers and companion surfaces. Recommended action remains integrate, but the retained value is selective effect infrastructure rather than a standalone feature lane.","Useful merge candidate for HyperTwist, primarily in the browser companion layer; strongest value sits in outline, SSAO, and effect-composer infrastructure beneath browser viewers.","Audit pmndrs/postprocessing as a bounded browser post-processing substrate for HyperTwist. Inspect composer, pass, outline, and SSAO behavior and decide what should remain direct dependency use versus conceptual reference.","HT_browser_surface_0007","HT_browser_surface","pmndrs/postprocessing","","","","","","","","Zlib","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is Zlib and direct use is allowed. Treat it as a bounded browser post-processing dependency.","Use directly as a bounded browser-side dependency beneath three.js-based viewers; keep HyperTwist product logic outside the upstream package.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless you later replace a narrow upstream layer for product-shaping reasons.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-24."
|
||||
"pmndrs/react-three-fiber","https://github.com/pmndrs/react-three-fiber","HyperTwist","Donor Bench","Browser React 3D substrate","P2","","","","","","medium","Retain it mainly as a dependency substrate. Keep HyperTwist domain logic, product shell, and runtime ownership above the upstream renderer.","repurpose","moderate modification","Determine whether react-three-fiber should remain the default React renderer substrate for browser companion scenes.","Canvas, createRoot, reconciler runtime, event system, hooks, native path","Inspect manifests, README/docs, fiber package runtime, core renderer code, event handling, hooks, and native entry points.","Inspect Canvas and createRoot behavior, reconciler and store wiring, event system, hooks, and the native path.","Repurpose selected subsystems rather than the whole product. Mine the repo for React renderer and event behavior, scene hook patterns, and browser companion ergonomics; keep what shortens build time, but leave HyperTwist product logic and owned runtime direction outside the upstream layer.","","Repurpose here means: use it as the bounded React renderer substrate for browser-side 3D and XR surfaces.","","","","","","","","","","","","Upgrade if source reveals unusually reusable browser-runtime seams, clean adapter boundaries, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos in the same lane.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed browser/XR capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended pairing or dependency posture; 5) Risks or licensing notes.","Primary: HT_browser_surface cluster packet plus the repo-specific Markdown dossier. Optional: companion browser/XR rows in the same cluster.","pmndrs/react-three-fiber is placed in Donor Bench for HyperTwist because it is the React runtime and event substrate above three.js for browser companion scenes. Recommended action remains repurpose, but the retained value is a bounded browser renderer layer rather than product differentiation.","Useful subsystem donor for HyperTwist, primarily in the browser companion layer; strongest current React renderer substrate above three.js in the stack.","Audit pmndrs/react-three-fiber as the React renderer substrate for HyperTwist browser companion scenes. Inspect Canvas, createRoot, event handling, hooks, and runtime boundaries. Decide which parts should remain direct dependency use versus conceptual reference.","HT_browser_surface_0008","HT_browser_surface","pmndrs/react-three-fiber","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser React renderer substrate.","Use directly as a bounded browser-side dependency above three.js; keep HyperTwist product logic and runtime ownership outside the upstream layer.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless you later replace a narrow upstream layer for product-shaping reasons.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-24."
|
||||
"pmndrs/drei","https://github.com/pmndrs/drei","HyperTwist","Merge Bench","Browser 3D helper and abstraction layer","P3","","","","","","medium","Retain only the helpers with direct product leverage. Keep HyperTwist product architecture outside the upstream abstraction sprawl.","integrate","moderate modification","Determine which drei helpers should remain active merge candidates for browser companion surfaces and which should be ignored as generic convenience.","Html overlays, View split rendering, TransformControls, Environment, Gltf helper behavior","Inspect manifests, README/docs, core and web helper components, TransformControls, Html, View, Environment, and Gltf wrappers.","Inspect Html overlay behavior, View split rendering, TransformControls, Environment setup, Gltf helpers, and staging utilities.","Integrate selected helpers rather than the whole package surface. Mine the repo for Html overlays, split-view handling, transform controls, staging, and selective asset helper behavior; keep what shortens build time, but avoid inheriting abstraction sprawl.","","Integrate here means: merge bounded browser helper abstractions into the companion stack where they materially reduce implementation cost.","","","","","","","","","","","","Upgrade if source reveals unusually reusable browser-runtime seams, clean adapter boundaries, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos in the same lane.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed browser/XR capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended pairing or dependency posture; 5) Risks or licensing notes.","Primary: HT_browser_surface cluster packet plus the repo-specific Markdown dossier. Optional: companion browser/XR rows in the same cluster.","pmndrs/drei is placed in Merge Bench for HyperTwist because it provides practical helper abstractions above react-three-fiber for browser companion surfaces. Recommended action remains integrate, but the retained value is selective helper and overlay behavior rather than a foundation.","Useful merge candidate for HyperTwist, primarily in the browser companion layer; strongest value sits in overlays, controls, split views, staging, and asset helper abstractions.","Audit pmndrs/drei as a bounded helper layer for HyperTwist browser companion scenes. Inspect Html, View, TransformControls, Environment, and Gltf helper behavior. Decide which utilities deserve active use and which should stay out to avoid abstraction sprawl.","HT_browser_surface_0009","HT_browser_surface","pmndrs/drei","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser helper layer above react-three-fiber.","Use directly as a bounded browser-side helper layer; keep HyperTwist product logic and architectural ownership outside the upstream package.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless you later replace a narrow upstream layer for product-shaping reasons.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-24."
|
||||
"pmndrs/xr","https://github.com/pmndrs/xr","HyperTwist","Donor Bench","Browser XR and immersive UI substrate","P2","","","","","","medium","Retain the useful XR interaction substrate, but keep HyperTwist product logic, permissions, and owned runtime direction outside the upstream stack.","repurpose","moderate modification","Determine whether pmndrs/xr should remain the default browser XR interaction donor for companion immersive surfaces.","XR store and runtime, dom overlay, controller locomotion, pointer-events, handle and manipulation layer","Inspect manifests, README/docs, xr store package, React bridge, dom-overlay, locomotion, pointer-events, and handle packages.","Inspect XR store/runtime, dom-overlay support, locomotion hooks, pointer-event model, and handle/manipulation behavior.","Repurpose selected subsystems rather than the whole product. Mine the repo for XR session state, dom-overlay, pointer interaction, locomotion, and manipulation behavior; keep what shortens build time, but bind it to HyperTwist browser companion flows and permissions.","","Repurpose here means: turn it into the bounded browser XR interaction substrate for immersive companion surfaces.","","","","","","","","","","","","Upgrade if source reveals unusually reusable browser-runtime seams, clean adapter boundaries, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos in the same lane.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed browser/XR capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended pairing or dependency posture; 5) Risks or licensing notes.","Primary: HT_browser_surface cluster packet plus the repo-specific Markdown dossier. Optional: companion browser/XR rows in the same cluster.","pmndrs/xr is placed in Donor Bench for HyperTwist because it provides the strongest current browser XR interaction substrate, including session state, pointer interaction, locomotion, and dom-overlay behavior. Recommended action remains repurpose, but the retained value is bounded browser XR infrastructure rather than runtime ownership.","Useful subsystem donor for HyperTwist, primarily in the browser companion layer; strongest current browser XR interaction and immersive UI donor in the stack.","Audit pmndrs/xr as the browser XR interaction substrate for HyperTwist companion surfaces. Inspect XR store/runtime, dom-overlay, locomotion, pointer-events, and handle behavior. Decide which pieces should remain direct use and which should stay conceptual.","HT_browser_surface_0010","HT_browser_surface","pmndrs/xr","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser XR interaction donor.","Use directly as a bounded browser-side XR dependency; keep HyperTwist product logic and runtime ownership outside the upstream stack.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless you later replace a narrow upstream layer for product-shaping reasons.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-24."
|
||||
"pmndrs/uikit","https://github.com/pmndrs/uikit","HyperTwist","Donor Bench","Browser spatial UI surface","P2","","","","","","medium","Retain the useful spatial UI substrate, but keep HyperTwist product logic, styling language, and runtime ownership outside the upstream package.","repurpose","moderate modification","Determine whether pmndrs/uikit should remain the default browser spatial UI donor for HyperTwist companion surfaces.","flex and yoga layout, clipping, scrolling, text and media components, Fullscreen and Container behavior","Inspect manifests, README/docs, react package, build runtime, core uikit components, Fullscreen, Container, and layout-related code.","Inspect spatial layout runtime, clipping and scrolling behavior, text and media components, Fullscreen, Container, and React bridge behavior.","Repurpose selected subsystems rather than the whole product. Mine the repo for spatial layout, clipping, scrolling, text, and fullscreen panel behavior; keep what shortens build time, but bind it to HyperTwist browser companion surfaces and interface design.","","Repurpose here means: turn it into the bounded browser spatial UI layer for dashboards, coach panels, and immersive menus.","","","","","","","","","","","","Upgrade if source reveals unusually reusable browser-runtime seams, clean adapter boundaries, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos in the same lane.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed browser/XR capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended pairing or dependency posture; 5) Risks or licensing notes.","Primary: HT_browser_surface cluster packet plus the repo-specific Markdown dossier. Optional: companion browser/XR rows in the same cluster.","pmndrs/uikit is placed in Donor Bench for HyperTwist because it provides the strongest current browser spatial UI layer with layout, clipping, text, scrolling, and panel behavior. Recommended action remains repurpose, but the retained value is bounded spatial interface infrastructure rather than runtime ownership.","Useful subsystem donor for HyperTwist, primarily in the browser companion layer; strongest current browser spatial UI and 3D interface donor in the stack.","Audit pmndrs/uikit as the browser spatial UI donor for HyperTwist companion surfaces. Inspect layout, clipping, scrolling, text/media components, and Fullscreen/Container behavior. Decide which parts deserve direct use and which should stay conceptual.","HT_browser_surface_0011","HT_browser_surface","pmndrs/uikit","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser spatial UI donor.","Use directly as a bounded browser-side dependency; keep HyperTwist product logic and styling ownership outside the upstream stack.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless you later replace a narrow upstream layer for product-shaping reasons.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-24."
|
||||
"pmndrs/react-spring","https://github.com/pmndrs/react-spring","HyperTwist","Merge Bench","Browser motion and animation layer","P3","","","","","","medium","Retain selective motion infrastructure, but keep HyperTwist product logic, page flows, and interface ownership outside the upstream package.","integrate","moderate modification","Determine which react-spring motion surfaces should remain active merge candidates for browser companion views.","Controller and SpringValue runtime, scheduler, layered explainer behavior, browser motion ergonomics","Inspect manifests, README/docs, core runtime, scheduler package, parallax package, and animated host behavior.","Inspect Controller and SpringValue runtime, scheduler behavior, parallax and layered motion, and browser integration patterns.","Integrate selected motion subsystems rather than the whole product. Mine the repo for spring motion runtime, scheduling, and layered explainer behavior; keep what shortens build time, but bind it to HyperTwist browser companion surfaces and interaction design.","","Integrate here means: merge bounded motion and layered explainer behavior into browser companion surfaces.","","","","","","","","","","","","Upgrade if source reveals unusually reusable browser-runtime seams, clean adapter boundaries, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos in the same lane.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed browser/XR capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended pairing or dependency posture; 5) Risks or licensing notes.","Primary: HT_browser_surface cluster packet plus the repo-specific Markdown dossier. Optional: companion browser/XR rows in the same cluster.","pmndrs/react-spring is placed in Merge Bench for HyperTwist because it provides the browser motion substrate beneath layered explainers and polished companion UI. Recommended action remains integrate, but the retained value is selective motion infrastructure rather than a product foundation.","Useful merge candidate for HyperTwist, primarily in the browser companion layer; strongest value sits in spring motion, scheduling, and layered browser explainer behavior.","Audit pmndrs/react-spring as a browser motion substrate for HyperTwist companion surfaces. Inspect core motion runtime, scheduling, layered explainer behavior, and browser integration patterns. Decide which parts deserve active use and which should stay conceptual.","HT_browser_surface_0012","HT_browser_surface","pmndrs/react-spring","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser motion substrate.","Use directly as a bounded browser-side dependency; keep HyperTwist product logic and page-flow ownership outside the upstream package.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless you later replace a narrow upstream layer for product-shaping reasons.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-24."
|
||||
"screenpipe/screenpipe","https://github.com/screenpipe/screenpipe","HyperTwist","Donor Bench","Support-plane capture, history, and replay sidecar","P2","","","","","","medium","Retain the valuable internal layer, but expect to replace upstream shell assumptions and rebind boundaries so it fits the HyperTwist architecture.","repurpose","moderate modification","Determine whether screenpipe/screenpipe should remain active in the Support-plane capture, history, and replay sidecar lane and which seams should stay bounded.","capture lifecycle, local engine seams, permission middleware, vault storage, timeline UX, notification surfaces","Inspect manifests, README/docs, engine/database/vault crates, app tauri surfaces, timeline UI, notification routes, and permission middleware.","the recording lifecycle, engine and database crates, permission model, rewind timeline behavior, notification routes, and vault handling.","Repurpose selected subsystems rather than the whole product. Mine the repo for local capture and replay architecture, permission-aware tooling, timeline behavior, vault storage, and notification support surfaces; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Repurpose here means: extract bounded support surfaces from this repo without inheriting the full upstream shell.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_support_sidecars cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","screenpipe/screenpipe is placed in Donor Bench for HyperTwist because it provides a strategic donor with care for local capture/history/replay, permissions-aware agents, encrypted vaults, and notification support surfaces, not a gameplay or vision foundation. Recommended action remains repurpose, but it should stay bounded to the Support-plane capture, history, and replay sidecar lane rather than reshape the core runtime.","Useful donor bench candidate for HyperTwist, primarily in the 'Support-plane capture, history, and replay sidecar' lane; a strategic donor with care for local capture/history/replay, permissions-aware agents, encrypted vaults, and notification support surfaces, not a gameplay or vision foundation.","Audit screenpipe/screenpipe as a Support-plane capture, history, and replay sidecar candidate for HyperTwist. Inspect the recording lifecycle, engine and database crates, permission model, rewind timeline behavior, notification routes, and vault handling. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_support_sidecars_0001","HT_support_sidecars","screenpipe/screenpipe","","","","","","","","MIT OR Apache-2.0 core; enterprise-restricted ee/","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 52-screenpipe-screenpipe-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","mixed_or_boundary_sensitive_known","bounded_sidecar_or_selective_reimplementation","The repo is permissive in its core paths but includes enterprise-restricted ee/ content. Use only clearly permissive core paths as bounded capture/history/replay donor material and exclude or reimplement enterprise-gated paths.","Use only clearly permissive core paths as bounded support-plane donor surfaces; exclude enterprise paths or reimplement equivalent seams.","Preserve permissive notices for reused core paths and do not incorporate ee/ without separate commercial rights.","Sometimes useful for enterprise-gated slices, but not required for clearly permissive core paths.","high","mixed-license-path-review-required","no","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 52-screenpipe-screenpipe-upstream-dossier.md"
|
||||
"remotion-dev/remotion","https://github.com/remotion-dev/remotion","HyperTwist","Donor Bench","Commercially licensed media-export and explainer sidecar","P2","","","","","","medium","Retain the valuable internal layer, but expect to replace upstream shell assumptions and rebind boundaries so it fits the HyperTwist architecture.","repurpose","moderate modification","Determine whether remotion-dev/remotion should remain active in the Media export and explainer sidecar lane and which seams should stay bounded.","player shell, renderer pipeline, studio/editor package, media parser, export workflow","Inspect manifests, LICENSE, README/docs, player package, renderer package, studio package, media-parser package, and major export/render entry points.","the player and renderer packages, studio/editor package, media-parser surfaces, export workflow, and custom commercial license boundaries.","Repurpose selected subsystems rather than the whole product. Mine the repo for media export, explainer rendering, embedded player behavior, and bounded browser or server-side export workflows; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Repurpose here means: extract bounded support surfaces from this repo without inheriting the full upstream shell.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_support_sidecars cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","remotion-dev/remotion is placed in Donor Bench for HyperTwist because it provides a bounded commercially licensed media-export and explainer sidecar, not a product foundation. Recommended action remains repurpose, but it should stay bounded to the Media export and explainer sidecar lane rather than reshape the core runtime.","Useful donor bench candidate for HyperTwist, primarily in the 'Media export and explainer sidecar' lane; a bounded commercially licensed media-export and explainer sidecar, not a product foundation.","Audit remotion-dev/remotion as a Media export and explainer sidecar candidate for HyperTwist. Inspect the player and renderer packages, studio/editor package, media-parser surfaces, export workflow, and custom commercial license boundaries. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_support_sidecars_0002","HT_support_sidecars","remotion-dev/remotion","","","","","","","","Custom two-tier commercial license","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 53-remotion-dev-remotion-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","mixed_or_boundary_sensitive_known","bounded_sidecar_or_selective_reimplementation","The repo uses a custom two-tier commercial license and should remain a bounded media-export and explainer sidecar. Review the commercial terms before direct use and do not treat it as a carefree donor.","Keep behind a bounded media-render/export seam; do not let it become a runtime foundation.","Preserve upstream license materials and satisfy the applicable commercial terms before shipping or internal deployment.","Sometimes useful only if later commercial terms or deployment constraints make direct use less attractive.","high","commercial-license-sidecar-review","no","","","","","","","","","","","","","v6.3_markdown_backfill","Refined on 2026-04-25 to the dossier-backed commercially licensed media-export and explainer sidecar posture."
|
||||
"ecomfe/zrender","https://github.com/ecomfe/zrender","HyperTwist","Merge Bench","Browser 2D render substrate","P3","","","","","","medium","Retain the reusable internal layer, but replace shell assumptions and rebind boundaries so it plugs into HyperTwist cleanly.","integrate","moderate modification","Determine whether ecomfe/zrender should remain active in the Browser 2D render substrate lane and which seams should stay bounded.","scene graph, canvas and SVG painters, event handling, animation primitives","Inspect manifests, README/docs, runtime entry, storage, painter implementations, event proxy, animation modules, and core graphic primitives.","the zrender runtime entry, scene storage, canvas and SVG painters, handler proxy, and animation behavior.","Integrate selected subsystems rather than the whole product. Mine the repo for 2D rendering, scene-graph, animation, and event-handling substrate behavior beneath browser reporting surfaces; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Integrate here means: merge bounded support surfaces from this repo into the HyperTwist companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","ecomfe/zrender is placed in Merge Bench for HyperTwist because it provides a lower-level 2D rendering and interaction substrate beneath echarts, not a separate strategic product lane. Recommended action remains integrate, but it should stay bounded to the Browser 2D render substrate lane rather than reshape the core runtime.","Useful merge bench candidate for HyperTwist, primarily in the 'Browser 2D render substrate' lane; a lower-level 2D rendering and interaction substrate beneath echarts, not a separate strategic product lane.","Audit ecomfe/zrender as a Browser 2D render substrate candidate for HyperTwist. Inspect the zrender runtime entry, scene storage, canvas and SVG painters, handler proxy, and animation behavior. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0001","HT_browser_support","ecomfe/zrender","","","","","","","","BSD-3-Clause","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 56-ecomfe-zrender-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is BSD-3-Clause and direct use is allowed. Treat it as a bounded 2D render substrate beneath the reporting stack.","Use directly as a bounded browser-side dependency beneath analytics and reporting layers.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless you later replace a narrow utility layer for product-shaping reasons.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 56-ecomfe-zrender-upstream-dossier.md"
|
||||
"pissang/claygl","https://github.com/pissang/claygl","HyperTwist","Merge Bench","Browser WebGL substrate","P3","","","","","","medium","Retain the reusable internal layer, but replace shell assumptions and rebind boundaries so it plugs into HyperTwist cleanly.","integrate","moderate modification","Determine whether pissang/claygl should remain active in the Browser WebGL substrate lane and which seams should stay bounded.","renderer, scene graph, cameras and controls, picking, compositor, loaders","Inspect manifests, README/docs, renderer, application, scene, controls, compositor, loader, and core geometry/material modules.","the renderer and application shell, scene behavior, camera and control plugins, picking, compositor, and loader surfaces.","Integrate selected subsystems rather than the whole product. Mine the repo for browser WebGL substrate, picking, controls, compositor behavior, and lightweight scene infrastructure; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Integrate here means: merge bounded support surfaces from this repo into the HyperTwist companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","pissang/claygl is placed in Merge Bench for HyperTwist because it provides a lower-level WebGL substrate beneath browser viewer and analytics surfaces, not a runtime foundation. Recommended action remains integrate, but it should stay bounded to the Browser WebGL substrate lane rather than reshape the core runtime.","Useful merge bench candidate for HyperTwist, primarily in the 'Browser WebGL substrate' lane; a lower-level WebGL substrate beneath browser viewer and analytics surfaces, not a runtime foundation.","Audit pissang/claygl as a Browser WebGL substrate candidate for HyperTwist. Inspect the renderer and application shell, scene behavior, camera and control plugins, picking, compositor, and loader surfaces. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0002","HT_browser_support","pissang/claygl","","","","","","","","BSD-style permissive (see LICENSE)","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 58-pissang-claygl-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The repo carries a BSD-style permissive license in its LICENSE file and direct use is viable. Treat it as a bounded WebGL substrate rather than a product lane.","Use directly as a bounded browser-side dependency after preserving the upstream license text.","Preserve the exact upstream LICENSE text and notices when redistributed or vendored.","Usually unnecessary unless you later replace a narrow low-level utility layer.","medium","license-text-normalization-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 58-pissang-claygl-upstream-dossier.md"
|
||||
"pissang/clay-viewer","https://github.com/pissang/clay-viewer","HyperTwist","Merge Bench","Browser viewer and editor sidecar","P3","","","","","","medium","Retain the reusable internal layer, but replace shell assumptions and rebind boundaries so it plugs into HyperTwist cleanly.","integrate","moderate modification","Determine whether pissang/clay-viewer should remain active in the Browser viewer and editor sidecar lane and which seams should stay bounded.","viewer shell, hotspot manager, environment and lighting config, post-effects, animation preview","Inspect manifests, README/docs, viewer runtime, default scene config, graphic effect compositor, and associated editor or UI shells.","the viewer shell, hotspot and picking behavior, default scene config, effect compositor, and animation-preview surfaces.","Integrate selected subsystems rather than the whole product. Mine the repo for browser viewer/editor behavior, hotspot handling, post-effects, lighting presets, and animation-preview support; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Integrate here means: merge bounded support surfaces from this repo into the HyperTwist companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","pissang/clay-viewer is placed in Merge Bench for HyperTwist because it provides a bounded browser viewer/editor sidecar with hotspot, environment, and post-effect surfaces, not a gameplay or runtime foundation. Recommended action remains integrate, but it should stay bounded to the Browser viewer and editor sidecar lane rather than reshape the core runtime.","Useful merge bench candidate for HyperTwist, primarily in the 'Browser viewer and editor sidecar' lane; a bounded browser viewer/editor sidecar with hotspot, environment, and post-effect surfaces, not a gameplay or runtime foundation.","Audit pissang/clay-viewer as a Browser viewer and editor sidecar candidate for HyperTwist. Inspect the viewer shell, hotspot and picking behavior, default scene config, effect compositor, and animation-preview surfaces. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0003","HT_browser_support","pissang/clay-viewer","","","","","","","","BSD-3-Clause","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 59-pissang-clay-viewer-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is BSD-3-Clause and direct use is allowed. Treat it as a bounded browser viewer/editor sidecar.","Use directly as a bounded browser-side dependency or sidecar for viewer/editor surfaces.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless later product-shaping concerns make selective replacement attractive.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 59-pissang-clay-viewer-upstream-dossier.md"
|
||||
"KhronosGroup/glTF-Sample-Renderer","https://github.com/KhronosGroup/glTF-Sample-Renderer","HyperTwist","Merge Bench","Browser asset renderer substrate","P3","","","","","","medium","Retain the reusable internal layer, but replace shell assumptions and rebind boundaries so it plugs into HyperTwist cleanly.","integrate","moderate modification","Determine whether KhronosGroup/glTF-Sample-Renderer should remain active in the Browser asset renderer substrate lane and which seams should stay bounded.","GltfView, GltfState, resource loader, user camera, renderer core","Inspect manifests, README/docs, renderer source tree, resource loader, GltfView, GltfState, user camera, and renderer integration points.","the GltfView and GltfState API surface, resource loader, renderer core, and user-camera behavior.","Integrate selected subsystems rather than the whole product. Mine the repo for standards-aware glTF loading, renderer substrate, camera state, and resource-loading behavior beneath asset viewers; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Integrate here means: merge bounded support surfaces from this repo into the HyperTwist companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","KhronosGroup/glTF-Sample-Renderer is placed in Merge Bench for HyperTwist because it provides the lower-level official glTF renderer substrate beneath glTF-Sample-Viewer, not a separate strategic lane. Recommended action remains integrate, but it should stay bounded to the Browser asset renderer substrate lane rather than reshape the core runtime.","Useful merge bench candidate for HyperTwist, primarily in the 'Browser asset renderer substrate' lane; the lower-level official glTF renderer substrate beneath glTF-Sample-Viewer, not a separate strategic lane.","Audit KhronosGroup/glTF-Sample-Renderer as a Browser asset renderer substrate candidate for HyperTwist. Inspect the GltfView and GltfState API surface, resource loader, renderer core, and user-camera behavior. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0004","HT_browser_support","khronosgroup/gltf-sample-renderer","","","","","","","","Apache-2.0","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 61-khronosgroup-gltf-sample-renderer-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is Apache-2.0 and direct use is allowed. Treat it as a bounded renderer substrate beneath asset viewers.","Use directly as a bounded browser-side dependency beneath asset inspection and preview tooling.","Preserve LICENSE and NOTICE materials where required.","Usually unnecessary unless later product-shaping concerns make selective replacement attractive.","high","notice-file-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 61-khronosgroup-gltf-sample-renderer-upstream-dossier.md"
|
||||
"google/model-viewer/packages/space-opera","https://github.com/google/model-viewer/tree/main/packages/space-opera","HyperTwist","Merge Bench","Browser asset editor and inspection surface","P3","","","","","","medium","Retain the reusable internal layer, but replace shell assumptions and rebind boundaries so it plugs into HyperTwist cleanly.","integrate","moderate modification","Determine whether google/model-viewer/packages/space-opera should remain active in the Browser asset editor and inspection surface lane and which seams should stay bounded.","editor shell, reducer and state structure, hotspot editing, snippet export, inspector surfaces","Inspect manifests, README/docs, app shell, reducers, hotspot panel, snippet generator, inspector components, and editor-adjacent modules.","the app shell, reducer and state structure, hotspot editing flow, snippet export surfaces, and inspector behavior.","Integrate selected subsystems rather than the whole product. Mine the repo for browser editor, inspection, hotspot editing, snippet export, and lightweight asset-authoring behavior; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Integrate here means: merge bounded support surfaces from this repo into the HyperTwist companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","google/model-viewer/packages/space-opera is placed in Merge Bench for HyperTwist because it provides a bounded browser editor and inspection donor beneath model-viewer, not a standalone product lane. Recommended action remains integrate, but it should stay bounded to the Browser asset editor and inspection surface lane rather than reshape the core runtime.","Useful merge bench candidate for HyperTwist, primarily in the 'Browser asset editor and inspection surface' lane; a bounded browser editor and inspection donor beneath model-viewer, not a standalone product lane.","Audit google/model-viewer/packages/space-opera as a Browser asset editor and inspection surface candidate for HyperTwist. Inspect the app shell, reducer and state structure, hotspot editing flow, snippet export surfaces, and inspector behavior. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0005","HT_browser_support","google/model-viewer/packages/space-opera","","","","","","","","Apache-2.0","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 63-google-space-opera-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is Apache-2.0 and direct use is allowed. Treat it as a bounded browser editor and inspection donor beneath model-viewer.","Use directly as a bounded browser-side dependency or concept donor beneath browser asset tooling.","Preserve LICENSE and NOTICE materials where required.","Usually unnecessary unless later product-shaping concerns make selective replacement attractive.","high","notice-file-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 63-google-space-opera-upstream-dossier.md"
|
||||
"google/model-viewer/packages/render-fidelity-tools","https://github.com/google/model-viewer/tree/main/packages/render-fidelity-tools","HyperTwist","Merge Bench","Browser fidelity QA harness","P3","","","","","","medium","Retain the reusable internal layer, but replace shell assumptions and rebind boundaries so it plugs into HyperTwist cleanly.","integrate","moderate modification","Determine whether google/model-viewer/packages/render-fidelity-tools should remain active in the Browser fidelity QA harness lane and which seams should stay bounded.","golden rendering, fidelity workflows, harness configuration, image comparison worker","Inspect manifests, README/docs, workflow scripts, renderer harness, image comparison worker, and fidelity-testing utilities.","the test-fidelity and render-goldens workflows, renderer harness behavior, image-comparison worker, and artifact generation.","Integrate selected subsystems rather than the whole product. Mine the repo for browser visual-regression workflows, golden rendering, fidelity thresholds, and harness configuration behavior; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Integrate here means: merge bounded support surfaces from this repo into the HyperTwist companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","google/model-viewer/packages/render-fidelity-tools is placed in Merge Bench for HyperTwist because it provides a bounded fidelity oracle and QA harness donor beneath model-viewer, not a runtime lane. Recommended action remains integrate, but it should stay bounded to the Browser fidelity QA harness lane rather than reshape the core runtime.","Useful merge bench candidate for HyperTwist, primarily in the 'Browser fidelity QA harness' lane; a bounded fidelity oracle and QA harness donor beneath model-viewer, not a runtime lane.","Audit google/model-viewer/packages/render-fidelity-tools as a Browser fidelity QA harness candidate for HyperTwist. Inspect the test-fidelity and render-goldens workflows, renderer harness behavior, image-comparison worker, and artifact generation. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0006","HT_browser_support","google/model-viewer/packages/render-fidelity-tools","","","","","","","","Apache-2.0","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 64-google-render-fidelity-tools-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is Apache-2.0 and direct use is allowed. Treat it as a bounded QA and fidelity-testing donor.","Use directly as a bounded browser-side QA dependency or concept donor for visual regression tooling.","Preserve LICENSE and NOTICE materials where required.","Usually unnecessary unless later product-shaping concerns make selective replacement attractive.","high","notice-file-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 64-google-render-fidelity-tools-upstream-dossier.md"
|
||||
"google/model-viewer/packages/model-viewer-effects","https://github.com/google/model-viewer/tree/main/packages/model-viewer-effects","HyperTwist","Merge Bench","Browser emphasis and post-processing extension","P3","","","","","","medium","Retain the reusable internal layer, but replace shell assumptions and rebind boundaries so it plugs into HyperTwist cleanly.","integrate","moderate modification","Determine whether google/model-viewer/packages/model-viewer-effects should remain active in the Browser emphasis and post-processing extension lane and which seams should stay bounded.","effect composer integration, outline, SSAO, emphasis behavior, custom-element surface","Inspect manifests, README/docs, effect-composer integration, custom-element wrapper, outline and SSAO effects, and related extension code.","the effect-composer integration, custom-element surface, outline effect, SSAO effect, and emphasis behavior.","Integrate selected subsystems rather than the whole product. Mine the repo for browser emphasis, outline and SSAO behavior, and effect-composer integration beneath browser model presentation; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Integrate here means: merge bounded support surfaces from this repo into the HyperTwist companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","google/model-viewer/packages/model-viewer-effects is placed in Merge Bench for HyperTwist because it provides a bounded browser post-processing and emphasis donor beneath model-viewer, not a standalone product lane. Recommended action remains integrate, but it should stay bounded to the Browser emphasis and post-processing extension lane rather than reshape the core runtime.","Useful merge bench candidate for HyperTwist, primarily in the 'Browser emphasis and post-processing extension' lane; a bounded browser post-processing and emphasis donor beneath model-viewer, not a standalone product lane.","Audit google/model-viewer/packages/model-viewer-effects as a Browser emphasis and post-processing extension candidate for HyperTwist. Inspect the effect-composer integration, custom-element surface, outline effect, SSAO effect, and emphasis behavior. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0007","HT_browser_support","google/model-viewer/packages/model-viewer-effects","","","","","","","","Apache-2.0","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 65-google-model-viewer-effects-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is Apache-2.0 and direct use is allowed. Treat it as a bounded browser emphasis and effect donor beneath model-viewer.","Use directly as a bounded browser-side dependency or concept donor beneath browser model presentation.","Preserve LICENSE and NOTICE materials where required.","Usually unnecessary unless later product-shaping concerns make selective replacement attractive.","high","notice-file-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 65-google-model-viewer-effects-upstream-dossier.md"
|
||||
"google/model-viewer/packages/modelviewer.dev","https://github.com/google/model-viewer/tree/main/packages/modelviewer.dev","HyperTwist","Merge Bench","Browser docs and demo surface","P4","","","","","","medium","Retain the reusable internal layer, but replace shell assumptions and rebind boundaries so it plugs into HyperTwist cleanly.","integrate","moderate modification","Determine whether google/model-viewer/packages/modelviewer.dev should remain active in the Browser docs and demo surface lane and which seams should stay bounded.","live docs generation, snippet-to-demo coupling, sidebar and HTML generation","Inspect manifests, README/docs, docs-and-examples code, example-snippet component, sidebar builder, and HTML generation utilities.","the docs-and-examples flow, example-snippet behavior, sidebar generation, and HTML generation surfaces.","Integrate selected subsystems rather than the whole product. Mine the repo for live docs and demo generation, snippet-to-demo coupling, and documentation information architecture; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Integrate here means: merge bounded support surfaces from this repo into the HyperTwist companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","google/model-viewer/packages/modelviewer.dev is placed in Merge Bench for HyperTwist because it provides a bounded docs and demo donor beneath model-viewer, not a runtime lane. Recommended action remains integrate, but it should stay bounded to the Browser docs and demo surface lane rather than reshape the core runtime.","Useful merge bench candidate for HyperTwist, primarily in the 'Browser docs and demo surface' lane; a bounded docs and demo donor beneath model-viewer, not a runtime lane.","Audit google/model-viewer/packages/modelviewer.dev as a Browser docs and demo surface candidate for HyperTwist. Inspect the docs-and-examples flow, example-snippet behavior, sidebar generation, and HTML generation surfaces. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0008","HT_browser_support","google/model-viewer/packages/modelviewer.dev","","","","","","","","Apache-2.0","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 66-google-modelviewer-dev-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is Apache-2.0 and direct use is allowed. Treat it as a bounded docs and demo donor.","Use directly as a bounded docs/demo dependency or concept donor for documentation surfaces.","Preserve LICENSE and NOTICE materials where required.","Usually unnecessary unless later product-shaping concerns make selective replacement attractive.","high","notice-file-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 66-google-modelviewer-dev-upstream-dossier.md"
|
||||
"google/model-viewer/packages/shared-assets","https://github.com/google/model-viewer/tree/main/packages/shared-assets","HyperTwist","Donor Bench","Boundary-sensitive sample-asset and test-fixture pack","P3","","","","","","medium","Retain the reusable internal layer, but replace shell assumptions and rebind boundaries so it plugs into HyperTwist cleanly.","repurpose","architecture only","Determine whether google/model-viewer/packages/shared-assets should remain active in the Browser sample-asset and fixture pack lane and which seams should stay bounded.","asset provenance, attribution terms, environment fixtures, sample models, fetch script behavior","Inspect manifests, README/docs, LICENSE, ATTRIBUTIONS, fixture assets, and asset-fetch scripts. Verify container license versus per-asset terms.","the attribution file, mixed per-asset terms, sample-model and environment fixture role, and fetch-script behavior.","Integrate selected subsystems rather than the whole product. Mine the repo for sample-model and environment-fixture selection, visual QA assets, and per-asset provenance handling; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Integrate here means: merge bounded support surfaces from this repo into the HyperTwist companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","Keep as a bounded fixture pack for local viewer tests, environment-lighting checks, and docs/examples, not as a normal code donor or blanket shippable asset source.","Mixed-provenance assets are still useful for fixtures and QA, but they should not sit in an active merge posture.","Audit google/model-viewer/packages/shared-assets as a Browser sample-asset and fixture pack candidate for HyperTwist. Inspect the attribution file, mixed per-asset terms, sample-model and environment fixture role, and fetch-script behavior. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0009","HT_browser_support","google/model-viewer/packages/shared-assets","","","","","","","","Apache-2.0 container; mixed per-asset terms","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 67-google-shared-assets-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","mixed_or_boundary_sensitive_known","bounded_sidecar_or_selective_reimplementation","The package container is Apache-2.0, but the actual payloads carry mixed per-asset terms. Treat it as a whitelisted fixture pack, not a blanket shippable asset source.","Whitelist individual acceptable assets only; do not assume the container license overrides per-asset terms.","Preserve container notices and review each selected asset attribution or usage condition separately before shipping.","Usually unnecessary; the main issue is per-asset provenance and selection, not code replacement.","high","mixed-asset-whitelist-review","no","","","","","","","","","","","","","v6.3_markdown_backfill","Corrected on 2026-04-25 from stale merge posture to dossier-backed boundary-sensitive fixture-pack status."
|
||||
"pmndrs/react-postprocessing","https://github.com/pmndrs/react-postprocessing","HyperTwist","Merge Bench","Browser React effect-wrapper layer","P4","","","","","","medium","Retain the reusable internal layer, but replace shell assumptions and rebind boundaries so it plugs into HyperTwist cleanly.","integrate","moderate modification","Determine whether pmndrs/react-postprocessing should remain active in the Browser React effect-wrapper layer lane and which seams should stay bounded.","React EffectComposer orchestration, selection model, wrapper ergonomics","Inspect manifests, README/docs, EffectComposer wrapper, Selection support, and the narrow React integration layer.","the React EffectComposer wrapper, Selection model, and integration assumptions on top of postprocessing and react-three-fiber.","Integrate selected subsystems rather than the whole product. Mine the repo for React-side effect orchestration, selection-based emphasis behavior, and wrapper ergonomics above browser post-processing; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Integrate here means: merge bounded support surfaces from this repo into the HyperTwist companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","pmndrs/react-postprocessing is placed in Merge Bench for HyperTwist because it provides a bounded React wrapper for the browser post-processing lane, not a standalone product lane. Recommended action remains integrate, but it should stay bounded to the Browser React effect-wrapper layer lane rather than reshape the core runtime.","Useful merge bench candidate for HyperTwist, primarily in the 'Browser React effect-wrapper layer' lane; a bounded React wrapper for the browser post-processing lane, not a standalone product lane.","Audit pmndrs/react-postprocessing as a Browser React effect-wrapper layer candidate for HyperTwist. Inspect the React EffectComposer wrapper, Selection model, and integration assumptions on top of postprocessing and react-three-fiber. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0010","HT_browser_support","pmndrs/react-postprocessing","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 70-pmndrs-react-postprocessing-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded React wrapper layer above browser post-processing.","Use directly as a bounded browser-side wrapper dependency above the core post-processing substrate.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless later product-shaping concerns make selective replacement attractive.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 70-pmndrs-react-postprocessing-upstream-dossier.md"
|
||||
"pmndrs/three-stdlib","https://github.com/pmndrs/three-stdlib","HyperTwist","Merge Bench","Browser 3D utility substrate","P4","","","","","","medium","Retain the reusable internal layer, but replace shell assumptions and rebind boundaries so it plugs into HyperTwist cleanly.","integrate","moderate modification","Determine whether pmndrs/three-stdlib should remain active in the Browser 3D utility substrate lane and which seams should stay bounded.","controls, loaders, WebXR helpers, post-processing helpers, utility exports","Inspect manifests, README/docs, utility index, controls, WebXR helpers, loaders, and exported utility modules.","the utility export surface, controls, loaders, WebXR helpers, post-processing helpers, and packaging of three/examples behavior.","Integrate selected subsystems rather than the whole product. Mine the repo for browser-side utility helpers, controls, loaders, and XR-adjacent primitives beneath the browser companion stack; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Integrate here means: merge bounded support surfaces from this repo into the HyperTwist companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","pmndrs/three-stdlib is placed in Merge Bench for HyperTwist because it provides a lower-level browser utility substrate beneath three.js, drei, and XR-adjacent lanes, not a product lane. Recommended action remains integrate, but it should stay bounded to the Browser 3D utility substrate lane rather than reshape the core runtime.","Useful merge bench candidate for HyperTwist, primarily in the 'Browser 3D utility substrate' lane; a lower-level browser utility substrate beneath three.js, drei, and XR-adjacent lanes, not a product lane.","Audit pmndrs/three-stdlib as a Browser 3D utility substrate candidate for HyperTwist. Inspect the utility export surface, controls, loaders, WebXR helpers, post-processing helpers, and packaging of three/examples behavior. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0011","HT_browser_support","pmndrs/three-stdlib","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 75-pmndrs-three-stdlib-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded utility substrate beneath three.js-adjacent browser lanes.","Use directly as a bounded browser-side utility dependency beneath higher-level viewer and XR layers.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless later product-shaping concerns make selective replacement attractive.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 75-pmndrs-three-stdlib-upstream-dossier.md"
|
||||
"pmndrs/maath","https://github.com/pmndrs/maath","HyperTwist","Merge Bench","Browser math-helper substrate","P4","","","","","","medium","Retain the reusable internal layer, but replace shell assumptions and rebind boundaries so it plugs into HyperTwist cleanly.","integrate","moderate modification","Determine whether pmndrs/maath should remain active in the Browser math-helper substrate lane and which seams should stay bounded.","easing and damp functions, random helpers, geometry utilities","Inspect manifests, README/docs, math package exports, easing, geometry, and random helper modules.","the easing runtime, random helpers, geometry utilities, and three.js-oriented math surfaces.","Integrate selected subsystems rather than the whole product. Mine the repo for browser-side easing, damping, sampling, and geometry helper behavior beneath interactive surfaces; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Integrate here means: merge bounded support surfaces from this repo into the HyperTwist companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","pmndrs/maath is placed in Merge Bench for HyperTwist because it provides a lower-level browser math-helper substrate beneath viewer and XR-adjacent lanes, not a product lane. Recommended action remains integrate, but it should stay bounded to the Browser math-helper substrate lane rather than reshape the core runtime.","Useful merge bench candidate for HyperTwist, primarily in the 'Browser math-helper substrate' lane; a lower-level browser math-helper substrate beneath viewer and XR-adjacent lanes, not a product lane.","Audit pmndrs/maath as a Browser math-helper substrate candidate for HyperTwist. Inspect the easing runtime, random helpers, geometry utilities, and three.js-oriented math surfaces. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0012","HT_browser_support","pmndrs/maath","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 76-pmndrs-maath-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded math-helper substrate.","Use directly as a bounded browser-side utility dependency beneath higher-level interactive layers.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless later product-shaping concerns make selective replacement attractive.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 76-pmndrs-maath-upstream-dossier.md"
|
||||
"pmndrs/zustand","https://github.com/pmndrs/zustand","HyperTwist","Donor Bench","Browser state-management substrate","P3","","","","","","medium","Retain the valuable internal layer, but expect to replace upstream shell assumptions and rebind boundaries so it fits the HyperTwist architecture.","repurpose","moderate modification","Determine whether pmndrs/zustand should remain active in the Browser state-management substrate lane and which seams should stay bounded.","vanilla store kernel, React bridge, selector subscriptions, persist and devtools middleware","Inspect manifests, README/docs, vanilla store, react bindings, traditional selector helpers, and middleware modules.","the vanilla store kernel, React bridge, selector subscriptions, persist middleware, devtools integration, and equality-aware selection behavior.","Repurpose selected subsystems rather than the whole product. Mine the repo for browser-side state management, selector subscriptions, hydration, and bridging between non-React logic and React views; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Repurpose here means: extract bounded support surfaces from this repo without inheriting the full upstream shell.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","pmndrs/zustand is placed in Donor Bench for HyperTwist because it provides a commodity strategic dependency for browser-side state management and selector subscriptions, not product differentiation. Recommended action remains repurpose, but it should stay bounded to the Browser state-management substrate lane rather than reshape the core runtime.","Useful donor bench candidate for HyperTwist, primarily in the 'Browser state-management substrate' lane; a commodity strategic dependency for browser-side state management and selector subscriptions, not product differentiation.","Audit pmndrs/zustand as a Browser state-management substrate candidate for HyperTwist. Inspect the vanilla store kernel, React bridge, selector subscriptions, persist middleware, devtools integration, and equality-aware selection behavior. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0013","HT_browser_support","pmndrs/zustand","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 77-pmndrs-zustand-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser state-management substrate.","Use directly as a bounded browser-side dependency for local state, selector subscriptions, and hydration behavior.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless later product-shaping concerns make selective replacement attractive.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 77-pmndrs-zustand-upstream-dossier.md"
|
||||
"pmndrs/leva","https://github.com/pmndrs/leva","HyperTwist","Merge Bench","Browser control-panel and parameter UI layer","P4","","","","","","medium","Retain the reusable internal layer, but replace shell assumptions and rebind boundaries so it plugs into HyperTwist cleanly.","integrate","moderate modification","Determine whether pmndrs/leva should remain active in the Browser control-panel and parameter UI layer lane and which seams should stay bounded.","control store, schema parsing, useControls, plugin system, headless mode","Inspect manifests, README/docs, store layer, useControls, panel components, plugin registration, and headless mode docs.","the control store, useControls schema parsing, plugin system, multi-panel behavior, and headless mode.","Integrate selected subsystems rather than the whole product. Mine the repo for parameter editing, control-panel behavior, headless control surfaces, and companion-surface tuning workflows; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Integrate here means: merge bounded support surfaces from this repo into the HyperTwist companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","pmndrs/leva is placed in Merge Bench for HyperTwist because it provides a bounded control-panel and headless parameter-UI donor for browser companion surfaces, not a runtime foundation. Recommended action remains integrate, but it should stay bounded to the Browser control-panel and parameter UI layer lane rather than reshape the core runtime.","Useful merge bench candidate for HyperTwist, primarily in the 'Browser control-panel and parameter UI layer' lane; a bounded control-panel and headless parameter-UI donor for browser companion surfaces, not a runtime foundation.","Audit pmndrs/leva as a Browser control-panel and parameter UI layer candidate for HyperTwist. Inspect the control store, useControls schema parsing, plugin system, multi-panel behavior, and headless mode. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0014","HT_browser_support","pmndrs/leva","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 78-pmndrs-leva-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser parameter-UI donor.","Use directly as a bounded browser-side dependency or concept donor for control panels and tuning UI.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless later product-shaping concerns make selective replacement attractive.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 78-pmndrs-leva-upstream-dossier.md"
|
||||
"pmndrs/use-gesture","https://github.com/pmndrs/use-gesture","HyperTwist","Donor Bench","Browser gesture and pointer-input substrate","P3","","","","","","medium","Retain the valuable internal layer, but expect to replace upstream shell assumptions and rebind boundaries so it fits the HyperTwist architecture.","repurpose","moderate modification","Determine whether pmndrs/use-gesture should remain active in the Browser gesture and pointer-input substrate lane and which seams should stay bounded.","gesture controller, drag engine, pointer capture, scroll prevention, React and vanilla bindings","Inspect manifests, README/docs, controller, gesture engines, React bindings, vanilla bindings, and input config parsing.","the core controller, drag engine, pointer capture and lock behavior, scroll prevention, and React versus vanilla bindings.","Repurpose selected subsystems rather than the whole product. Mine the repo for browser gesture handling, richer pointer input, drag and scroll behavior, and bounded interaction substrate; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Repurpose here means: extract bounded support surfaces from this repo without inheriting the full upstream shell.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","pmndrs/use-gesture is placed in Donor Bench for HyperTwist because it provides a commodity browser gesture and richer pointer-input substrate, not product differentiation. Recommended action remains repurpose, but it should stay bounded to the Browser gesture and pointer-input substrate lane rather than reshape the core runtime.","Useful donor bench candidate for HyperTwist, primarily in the 'Browser gesture and pointer-input substrate' lane; a commodity browser gesture and richer pointer-input substrate, not product differentiation.","Audit pmndrs/use-gesture as a Browser gesture and pointer-input substrate candidate for HyperTwist. Inspect the core controller, drag engine, pointer capture and lock behavior, scroll prevention, and React versus vanilla bindings. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0015","HT_browser_support","pmndrs/use-gesture","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 79-pmndrs-use-gesture-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser gesture and pointer-input substrate.","Use directly as a bounded browser-side dependency for custom viewers, panels, and interaction surfaces.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless later product-shaping concerns make selective replacement attractive.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 79-pmndrs-use-gesture-upstream-dossier.md"
|
||||
"@react-spring/parallax","https://github.com/pmndrs/react-spring/tree/main/packages/parallax","HyperTwist","Merge Bench","Browser layered-motion and explainer sidecar","P4","","","","","","medium","Retain the reusable internal layer, but replace shell assumptions and rebind boundaries so it plugs into HyperTwist cleanly.","integrate","moderate modification","Determine whether @react-spring/parallax should remain active in the Browser layered-motion and explainer sidecar lane and which seams should stay bounded.","layered page-space runtime, sticky layers, scroll-driven spring behavior, scrollTo","Inspect manifests, README/docs, parallax package runtime, layer behavior, and scroll-controller code.","the parallax runtime, sticky-layer behavior, scroll-driven spring motion, and imperative scrollTo flow.","Integrate selected subsystems rather than the whole product. Mine the repo for layered explainer behavior, scroll-driven motion, sticky layers, and narrative browser presentation; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Integrate here means: merge bounded support surfaces from this repo into the HyperTwist companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","@react-spring/parallax is placed in Merge Bench for HyperTwist because it provides a bounded layered-motion and explainer sidecar beneath react-spring, not a runtime lane. Recommended action remains integrate, but it should stay bounded to the Browser layered-motion and explainer sidecar lane rather than reshape the core runtime.","Useful merge bench candidate for HyperTwist, primarily in the 'Browser layered-motion and explainer sidecar' lane; a bounded layered-motion and explainer sidecar beneath react-spring, not a runtime lane.","Audit @react-spring/parallax as a Browser layered-motion and explainer sidecar candidate for HyperTwist. Inspect the parallax runtime, sticky-layer behavior, scroll-driven spring motion, and imperative scrollTo flow. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0016","HT_browser_support","@react-spring/parallax","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 81-react-spring-parallax-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded layered-motion and explainer sidecar.","Use directly as a bounded browser-side dependency for explainer and narrative surfaces.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless later product-shaping concerns make selective replacement attractive.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 81-react-spring-parallax-upstream-dossier.md"
|
||||
"@react-spring/rafz","https://github.com/pmndrs/react-spring/tree/main/packages/rafz","HyperTwist","Merge Bench","Browser frame-loop and scheduling utility","P4","","","","","","medium","Retain the reusable internal layer, but replace shell assumptions and rebind boundaries so it plugs into HyperTwist cleanly.","integrate","moderate modification","Determine whether @react-spring/rafz should remain active in the Browser frame-loop and scheduling utility lane and which seams should stay bounded.","phased queues, timeout scheduling, throttling, demand versus always loop control","Inspect manifests, README/docs, rafz package runtime, frame-loop scheduling, timeout handling, and queue behavior.","the frame-loop phases, timeout scheduling, throttling, batched updates hook, and demand versus always control behavior.","Integrate selected subsystems rather than the whole product. Mine the repo for browser scheduling, phased queues, timeout handling, and motion-frame orchestration beneath higher-level UI motion; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Integrate here means: merge bounded support surfaces from this repo into the HyperTwist companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","@react-spring/rafz is placed in Merge Bench for HyperTwist because it provides a lower-level browser frame-loop and scheduling utility beneath react-spring, not a product lane. Recommended action remains integrate, but it should stay bounded to the Browser frame-loop and scheduling utility lane rather than reshape the core runtime.","Useful merge bench candidate for HyperTwist, primarily in the 'Browser frame-loop and scheduling utility' lane; a lower-level browser frame-loop and scheduling utility beneath react-spring, not a product lane.","Audit @react-spring/rafz as a Browser frame-loop and scheduling utility candidate for HyperTwist. Inspect the frame-loop phases, timeout scheduling, throttling, batched updates hook, and demand versus always control behavior. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0017","HT_browser_support","@react-spring/rafz","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 82-react-spring-rafz-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded browser scheduling utility.","Use directly as a bounded browser-side dependency beneath higher-level motion or interaction layers.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless later product-shaping concerns make selective replacement attractive.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 82-react-spring-rafz-upstream-dossier.md"
|
||||
"@react-spring/animated","https://github.com/pmndrs/react-spring/tree/main/packages/animated","HyperTwist","Merge Bench","Browser animatable-component substrate","P4","","","","","","medium","Retain the reusable internal layer, but replace shell assumptions and rebind boundaries so it plugs into HyperTwist cleanly.","integrate","moderate modification","Determine whether @react-spring/animated should remain active in the Browser animatable-component substrate lane and which seams should stay bounded.","host creation, animated wrapper behavior, dependency observation, native-update fallback","Inspect manifests, README/docs, animated package runtime, host creation, animated wrapper, and animated base-node behavior.","the host-creation runtime, withAnimated wrapper, dependency observation, and native-update versus rerender behavior.","Integrate selected subsystems rather than the whole product. Mine the repo for animatable-component hosting, animated-props observation, and low-level motion binding beneath higher-level browser motion; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Integrate here means: merge bounded support surfaces from this repo into the HyperTwist companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","@react-spring/animated is placed in Merge Bench for HyperTwist because it provides a lower-level animatable-component host and animated-props substrate beneath react-spring, not a product lane. Recommended action remains integrate, but it should stay bounded to the Browser animatable-component substrate lane rather than reshape the core runtime.","Useful merge bench candidate for HyperTwist, primarily in the 'Browser animatable-component substrate' lane; a lower-level animatable-component host and animated-props substrate beneath react-spring, not a product lane.","Audit @react-spring/animated as a Browser animatable-component substrate candidate for HyperTwist. Inspect the host-creation runtime, withAnimated wrapper, dependency observation, and native-update versus rerender behavior. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0018","HT_browser_support","@react-spring/animated","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 83-react-spring-animated-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded animatable-component substrate.","Use directly as a bounded browser-side dependency beneath higher-level motion and UI layers.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless later product-shaping concerns make selective replacement attractive.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 83-react-spring-animated-upstream-dossier.md"
|
||||
"@react-spring/core","https://github.com/pmndrs/react-spring/tree/main/packages/core","HyperTwist","Donor Bench","Browser spring-runtime core","P3","","","","","","medium","Retain the valuable internal layer, but expect to replace upstream shell assumptions and rebind boundaries so it fits the HyperTwist architecture.","repurpose","moderate modification","Determine whether @react-spring/core should remain active in the Browser spring-runtime core lane and which seams should stay bounded.","controller orchestration, SpringValue runtime, useSprings lifecycle, frame advancement","Inspect manifests, README/docs, core package runtime, Controller, SpringValue, and hook lifecycle behavior.","the Controller runtime, SpringValue motion engine, useSprings lifecycle, queueing, start-stop behavior, and frame advancement.","Repurpose selected subsystems rather than the whole product. Mine the repo for browser motion runtime, spring orchestration, frame advancement, and reusable motion-core behavior beneath higher-level UI layers; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Repurpose here means: extract bounded support surfaces from this repo without inheriting the full upstream shell.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","@react-spring/core is placed in Donor Bench for HyperTwist because it provides the platform-agnostic spring-runtime core beneath react-spring, not a product foundation. Recommended action remains repurpose, but it should stay bounded to the Browser spring-runtime core lane rather than reshape the core runtime.","Useful donor bench candidate for HyperTwist, primarily in the 'Browser spring-runtime core' lane; the platform-agnostic spring-runtime core beneath react-spring, not a product foundation.","Audit @react-spring/core as a Browser spring-runtime core candidate for HyperTwist. Inspect the Controller runtime, SpringValue motion engine, useSprings lifecycle, queueing, start-stop behavior, and frame advancement. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0019","HT_browser_support","@react-spring/core","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 84-react-spring-core-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded spring-runtime core beneath higher-level motion layers.","Use directly as a bounded browser-side dependency beneath higher-level motion and interaction layers.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless later product-shaping concerns make selective replacement attractive.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 84-react-spring-core-upstream-dossier.md"
|
||||
"@react-spring/shared","https://github.com/pmndrs/react-spring/tree/main/packages/shared","HyperTwist","Merge Bench","Browser motion utility substrate","P4","","","","","","medium","Retain the reusable internal layer, but replace shell assumptions and rebind boundaries so it plugs into HyperTwist cleanly.","integrate","moderate modification","Determine whether @react-spring/shared should remain active in the Browser motion utility substrate lane and which seams should stay bounded.","globals customization, frame loop, interpolation helpers, fluid observer substrate","Inspect manifests, README/docs, shared package exports, globals, frame loop, interpolation, and fluid observer modules.","the globals customization seams, frame-loop behavior, interpolation helpers, and fluid observer substrate.","Integrate selected subsystems rather than the whole product. Mine the repo for motion utilities, frame-loop customization, interpolation, and fluid observation beneath higher-level browser motion; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Integrate here means: merge bounded support surfaces from this repo into the HyperTwist companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","@react-spring/shared is placed in Merge Bench for HyperTwist because it provides a lower-level motion utility and fluid-observer substrate beneath react-spring, not a product lane. Recommended action remains integrate, but it should stay bounded to the Browser motion utility substrate lane rather than reshape the core runtime.","Useful merge bench candidate for HyperTwist, primarily in the 'Browser motion utility substrate' lane; a lower-level motion utility and fluid-observer substrate beneath react-spring, not a product lane.","Audit @react-spring/shared as a Browser motion utility substrate candidate for HyperTwist. Inspect the globals customization seams, frame-loop behavior, interpolation helpers, and fluid observer substrate. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0020","HT_browser_support","@react-spring/shared","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 85-react-spring-shared-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded motion utility substrate.","Use directly as a bounded browser-side dependency beneath higher-level motion layers.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless later product-shaping concerns make selective replacement attractive.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 85-react-spring-shared-upstream-dossier.md"
|
||||
"@react-spring/types","https://github.com/pmndrs/react-spring/tree/main/packages/types","HyperTwist","Merge Bench","Browser motion type-contract substrate","P4","","","","","","medium","Retain the reusable internal layer, but replace shell assumptions and rebind boundaries so it plugs into HyperTwist cleanly.","integrate","moderate modification","Determine whether @react-spring/types should remain active in the Browser motion type-contract substrate lane and which seams should stay bounded.","shared type contracts, animatable types, interpolation types, utility types","Inspect manifests, type package exports, shared type files, interpolation type definitions, and utility-type modules.","the shared type-contract surface, animatable and interpolation types, and utility-type exports used across react-spring packages.","Integrate selected subsystems rather than the whole product. Mine the repo for shared type contracts and package-design substrate beneath browser motion layers; keep what materially shortens build time, but bind it to HyperTwist-owned data contracts, UI shell, and runtime boundaries.","","Integrate here means: merge bounded support surfaces from this repo into the HyperTwist companion stack.","","","","","","","","","","","","Upgrade if source reveals unusually reusable internal seams, clean adapters, robust tests, and direct leverage for HyperTwist companion surfaces.","Demote if retained value is mostly commodity glue, tightly bound to upstream shell assumptions, or clearly dominated by stronger neighboring repos.","Capability inventory + salvage targets + donor-tier verdict","1) Confirmed source-backed capabilities; 2) Best retained modules; 3) Boundaries to keep outside HyperTwist core; 4) Recommended dependency or merge posture; 5) Risks or licensing notes.","Primary: HT_browser_support cluster packet plus the repo-specific Markdown dossier. Optional: neighboring browser/support rows in the same cluster.","@react-spring/types is placed in Merge Bench for HyperTwist because it provides a narrow type-contract substrate beneath react-spring, not a behavior-heavy donor or product lane. Recommended action remains integrate, but it should stay bounded to the Browser motion type-contract substrate lane rather than reshape the core runtime.","Useful merge bench candidate for HyperTwist, primarily in the 'Browser motion type-contract substrate' lane; a narrow type-contract substrate beneath react-spring, not a behavior-heavy donor or product lane.","Audit @react-spring/types as a Browser motion type-contract substrate candidate for HyperTwist. Inspect the shared type-contract surface, animatable and interpolation types, and utility-type exports used across react-spring packages. Decide whether the retained value should remain active and what should stay bounded outside the HyperTwist core.","HT_browser_support_0021","HT_browser_support","@react-spring/types","","","","","","","","MIT","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","Backfilled from canonized Markdown dossier pass on 2026-04-25: 86-react-spring-types-upstream-dossier.md","v6_unified_source_of_truth_pack","","","","permissive_or_noncopyleft_known","direct_incorporation_ok","The code license is MIT and direct use is allowed. Treat it as a bounded type-contract substrate.","Use directly as a bounded browser-side dependency where those contracts are actually needed.","Typically preserve notices, attribution, and license text where required.","Usually unnecessary unless later product-shaping concerns make selective replacement attractive.","high","standard-notice-review","yes","","","","","","","","","","","","","v6.3_markdown_backfill","Backfilled from canonized Markdown dossier pass on 2026-04-25: 86-react-spring-types-upstream-dossier.md"
|
||||
|
BIN
docs/repo_portfolio_unified_v6_3.xlsx
Normal file
BIN
docs/repo_portfolio_unified_v6_3.xlsx
Normal file
Binary file not shown.
710
docs/repo_portfolio_unified_v6_3_README.txt
Normal file
710
docs/repo_portfolio_unified_v6_3_README.txt
Normal file
|
|
@ -0,0 +1,710 @@
|
|||
Here is what each document or folder is for, in plain English.
|
||||
|
||||
## The core v6.3 portfolio files
|
||||
|
||||
These are the **main portfolio-control documents**. They are the closest thing to your master decision system.
|
||||
|
||||
### `repo_portfolio_unified_v6_3_README.txt`
|
||||
|
||||
This is the **front door** to the v6.3 pack.
|
||||
|
||||
Its job is to explain:
|
||||
|
||||
* what the v6.3 pack is
|
||||
* which files inside it are authoritative
|
||||
* how the files relate to each other
|
||||
* what changed from earlier versions
|
||||
* how to use the pack without getting lost
|
||||
|
||||
In plain English: this is the **orientation sheet**.
|
||||
A model or human should read this first before touching the other files.
|
||||
|
||||
---
|
||||
|
||||
### `repo_portfolio_unified_branch_seed_prompt_v6_3.md`
|
||||
|
||||
This is the **bootstrapping prompt for new threads, new models, or crashed sessions**.
|
||||
|
||||
Its purpose is to give a fresh model enough context to re-enter the project without hallucinating a new architecture. It tells the model:
|
||||
|
||||
* what the projects are
|
||||
* what the authority order is
|
||||
* what the repo portfolio is for
|
||||
* how to think about inclusion, merger, donor logic, copy-left, and implementation posture
|
||||
* what not to do
|
||||
|
||||
In plain English: this is the **relaunch prompt**.
|
||||
When you open a new model session, this is one of the best files to feed it first.
|
||||
|
||||
---
|
||||
|
||||
### `repo_portfolio_unified_consolidation_and_init_prompt_v6_3.md`
|
||||
|
||||
This is the **canonical summary + initialization guide** for the whole portfolio.
|
||||
|
||||
It is slightly different from the branch seed prompt.
|
||||
The branch seed prompt is more about **starting a fresh reasoning session**.
|
||||
The consolidation/init prompt is more about **putting the whole universe in one coherent frame**.
|
||||
|
||||
Its purpose is to:
|
||||
|
||||
* summarize the final project posture
|
||||
* preserve important architectural corrections and overrides
|
||||
* explain how the portfolio should be interpreted
|
||||
* give a model a stable conceptual map before it starts repo work
|
||||
|
||||
In plain English: this is the **canonical worldview file**.
|
||||
It tells a model what the portfolio means.
|
||||
|
||||
---
|
||||
|
||||
### `repo_portfolio_unified_cluster_narratives_v6_3.csv`
|
||||
|
||||
This file groups repos into **families or clusters** and explains them in prose.
|
||||
|
||||
Instead of looking at repos one by one, this file helps you see:
|
||||
|
||||
* which repos belong to the same ecosystem
|
||||
* which repos are all solving related problems
|
||||
* which families matter to which project
|
||||
* how the families differ internally
|
||||
|
||||
Examples of cluster types:
|
||||
|
||||
* platform/orchestration/observability
|
||||
* security/recon/offensive-defensive
|
||||
* reverse-engineering/SRE
|
||||
* puzzle/hypercube/simulation
|
||||
* research/editor/corpus/workspace
|
||||
|
||||
In plain English: this is the **family-level explanation file**.
|
||||
It helps you understand the repo universe in chunks instead of one repo at a time.
|
||||
|
||||
---
|
||||
|
||||
### `repo_portfolio_unified_merger_matrix_v6_3.csv`
|
||||
|
||||
This is the **repo combination and synergy file**.
|
||||
|
||||
Its purpose is to answer:
|
||||
|
||||
* which repo should be foundation
|
||||
* which repo should be donor
|
||||
* which repos should be merged conceptually
|
||||
* which repo upgrades another
|
||||
* which repo should replace another
|
||||
* which repo is only useful in combination with another
|
||||
|
||||
It is specifically about **composite software futures**:
|
||||
|
||||
* foundation repo + feature donor
|
||||
* engine repo + UI donor
|
||||
* sidecar repo + native core
|
||||
* graph repo + visualization donor
|
||||
* security engine + spatial runtime
|
||||
* editor surface + research engine
|
||||
|
||||
In plain English: this is the **“what combines with what” file**.
|
||||
It is not mainly about whether a repo is good alone. It is about what it becomes when combined.
|
||||
|
||||
---
|
||||
|
||||
### `repo_portfolio_unified_re_layer_matrix_v6_3.csv`
|
||||
|
||||
This is the **reverse-engineering and binary-analysis special layer file**.
|
||||
|
||||
It exists because the RE/SRE family became important enough that it needed its own focused matrix.
|
||||
|
||||
Its purpose is to organize tools like:
|
||||
|
||||
* Ghidra
|
||||
* Rizin
|
||||
* Cutter
|
||||
* radare2
|
||||
* ImHex
|
||||
* angr
|
||||
* RetDec
|
||||
* Frida
|
||||
* Capstone / Keystone / Unicorn / LIEF
|
||||
* dnSpy / ILSpy and related tools
|
||||
|
||||
It also preserves the **Stratum 1–4 model**:
|
||||
|
||||
* Stratum 1: analyst surfaces
|
||||
* Stratum 2: automation engines
|
||||
* Stratum 3: primitive libraries
|
||||
* Stratum 4: glue / companions
|
||||
|
||||
In plain English: this is the **serious RE-layer planning file**.
|
||||
It tells you how binary-analysis tools fit into VectorShell and related workflows.
|
||||
|
||||
---
|
||||
|
||||
### `repo_portfolio_unified_copyleft_strategy_matrix_v6_3.csv`
|
||||
|
||||
This is the **license strategy and incorporation-mode file**.
|
||||
|
||||
Its purpose is not just to tell you a repo license.
|
||||
It tells you what to **do** about the license.
|
||||
|
||||
For each relevant repo, it tries to capture:
|
||||
|
||||
* whether copy-left matters
|
||||
* whether to incorporate as-is
|
||||
* whether to keep it as a bounded sidecar
|
||||
* whether to reverse engineer / clean-room reimplement
|
||||
* whether it should be pattern-only
|
||||
* why that choice makes sense
|
||||
|
||||
This is the file that encodes the philosophy you explicitly agreed to:
|
||||
|
||||
* GPL/AGPL are not exclusion filters
|
||||
* reverse engineering is not automatically mandatory
|
||||
* direct incorporation is not automatically best
|
||||
* the correct answer is repo-by-repo
|
||||
|
||||
In plain English: this is the **“how to use copyleft repos intelligently” file**.
|
||||
|
||||
---
|
||||
|
||||
### `repo_portfolio_unified_vscode_packets_v6_3.csv`
|
||||
|
||||
This is one of the most practically useful files.
|
||||
|
||||
It contains **repo-specific inspection packets** intended for coding models in VS Code or similar environments.
|
||||
|
||||
Its purpose is to tell a source-inspecting model:
|
||||
|
||||
* what repo to inspect
|
||||
* what to look for
|
||||
* what hidden value might be inside
|
||||
* what questions need answering
|
||||
* what the likely integration paths are
|
||||
* what would upgrade or downgrade the repo after source inspection
|
||||
|
||||
In plain English: this is the **source-audit handoff file**.
|
||||
It turns the portfolio into executable repo-by-repo inspection tasks.
|
||||
|
||||
---
|
||||
|
||||
### `repo_portfolio_unified_source_audit_v6_3.csv`
|
||||
|
||||
This is the **repo audit campaign file**.
|
||||
|
||||
It is broader than the VS Code packets file.
|
||||
|
||||
Its purpose is to organize:
|
||||
|
||||
* which repos should be audited first
|
||||
* which ones are P0, P1, P2, P3 style priorities
|
||||
* which ones matter most immediately
|
||||
* which ones can wait
|
||||
* what kind of audit each repo needs
|
||||
|
||||
If the VS Code packets are the **repo-level briefing cards**, this source audit file is the **campaign map**.
|
||||
|
||||
In plain English: this is the **priority and sequencing file for real repo inspection**.
|
||||
|
||||
---
|
||||
|
||||
### `repo_portfolio_unified_phase_g_v6_3.csv`
|
||||
|
||||
This is the **high-level adjudication board**.
|
||||
|
||||
This is where a repo gets its current broad portfolio decision, such as:
|
||||
|
||||
* locked foundation
|
||||
* locked parallel foundation
|
||||
* locked strategic donor
|
||||
* donor bench
|
||||
* merge bench
|
||||
* reserve bench
|
||||
* comparator / legacy
|
||||
* exclude current horizon
|
||||
* integrated product surface
|
||||
* implemented pattern source
|
||||
|
||||
It is the most useful file when you want the answer to:
|
||||
|
||||
* where does this repo currently stand?
|
||||
* how important is it?
|
||||
* which project does it belong to?
|
||||
* what broad bucket is it in?
|
||||
|
||||
In plain English: this is the **final classification board**.
|
||||
|
||||
---
|
||||
|
||||
### `repo_portfolio_unified_operational_v6_3.csv`
|
||||
|
||||
This is the **detailed working board**.
|
||||
|
||||
If the Phase G file gives the big judgment, the operational file explains the **practical meaning** of that judgment.
|
||||
|
||||
It usually contains richer detail around:
|
||||
|
||||
* what the repo actually contributes
|
||||
* how it could be integrated
|
||||
* what “repurpose” means in practice
|
||||
* whether it is direct, moderate modification, heavy modification, architecture-only, or concept-only
|
||||
* implementation implications
|
||||
* execution priority
|
||||
* portfolio priority
|
||||
|
||||
In plain English: this is the **“how to actually use the repo” file**.
|
||||
|
||||
---
|
||||
|
||||
### `repo_portfolio_unified_v6_3.xlsx`
|
||||
|
||||
This is the **human-friendly workbook version** of the portfolio.
|
||||
|
||||
Its job is not to replace the CSVs.
|
||||
Its job is to make the whole system easier to browse.
|
||||
|
||||
Usually its purpose is:
|
||||
|
||||
* let you open the portfolio in a spreadsheet interface
|
||||
* inspect the major boards without manually stitching CSVs together
|
||||
* hand a model or human a more navigable summary artifact
|
||||
* provide sheets that point to the more detailed data
|
||||
|
||||
In plain English: this is the **spreadsheet doorway into the portfolio**.
|
||||
|
||||
---
|
||||
|
||||
## The narrative companion bundles
|
||||
|
||||
These are not the master adjudication files.
|
||||
They are the **prose interpretation layers**.
|
||||
|
||||
They turn the portfolio from spreadsheets into readable narrative.
|
||||
|
||||
---
|
||||
|
||||
### `vectorshell_narrative_bundle_v1`
|
||||
|
||||
This folder contains the **VectorShell narrative companion**.
|
||||
|
||||
It includes:
|
||||
|
||||
#### `VectorShell_Volume_0.md`
|
||||
|
||||
This is the **preface and rules volume** for VectorShell.
|
||||
|
||||
Its purpose is to explain:
|
||||
|
||||
* what the VectorShell narrative bundle is
|
||||
* what authority order it follows
|
||||
* what collapse rules were applied
|
||||
* what VectorShell’s active posture is
|
||||
* how to interpret the rest of the bundle
|
||||
|
||||
In plain English: this is the **intro and interpretation frame**.
|
||||
|
||||
#### `VectorShell_Volume_1.md`
|
||||
|
||||
This is the **main VectorShell repo narrative volume**.
|
||||
|
||||
It contains the repos that are primarily VectorShell-first:
|
||||
|
||||
* foundations
|
||||
* core donors
|
||||
* primary candidates
|
||||
* main runtime and security/RE-adjacent components
|
||||
|
||||
In plain English: this is the **main story of which repos matter directly to VectorShell**.
|
||||
|
||||
#### `VectorShell_Volume_4.md`
|
||||
|
||||
This is the **cross-project and adjacent-use volume for VectorShell**.
|
||||
|
||||
It contains repos that are:
|
||||
|
||||
* not primarily VectorShell repos
|
||||
* but still useful to VectorShell
|
||||
* or transferable to it
|
||||
* or useful as reserve, comparator, donor, or adjacent tools
|
||||
|
||||
In plain English: this is the **extended universe around VectorShell**.
|
||||
|
||||
---
|
||||
|
||||
### `hypertwist_narrative_bundle_v1`
|
||||
|
||||
This folder contains the **HyperTwist narrative companion**.
|
||||
|
||||
It includes:
|
||||
|
||||
#### `HyperTwist_Volume_0.md`
|
||||
|
||||
The HyperTwist preface and rules volume.
|
||||
|
||||
It explains:
|
||||
|
||||
* how to read the HyperTwist repo narratives
|
||||
* what the active architecture posture is
|
||||
* what the dual-pillar structure is
|
||||
* what authority order governs the bundle
|
||||
|
||||
In plain English: the **interpretive intro for HyperTwist**.
|
||||
|
||||
#### `HyperTwist_Volume_2.md`
|
||||
|
||||
This is the **main HyperTwist repo narrative volume**.
|
||||
|
||||
It contains repos that are primarily HyperTwist-first:
|
||||
|
||||
* simulation foundations
|
||||
* CV and recognition layers
|
||||
* replay and training systems
|
||||
* coaching layers
|
||||
* hypercube-related foundations
|
||||
|
||||
In plain English: this is the **main HyperTwist repo story**.
|
||||
|
||||
#### `HyperTwist_Volume_4.md`
|
||||
|
||||
This is the **cross-project and adjacent-use volume for HyperTwist**.
|
||||
|
||||
It includes repos that are:
|
||||
|
||||
* not primarily HyperTwist-first
|
||||
* but could donate value to HyperTwist
|
||||
* or are reserve/comparator/cross-project relevant
|
||||
|
||||
In plain English: this is the **broader HyperTwist ecosystem layer**.
|
||||
|
||||
---
|
||||
|
||||
### `scriptoriumai_narrative_bundle_v1`
|
||||
|
||||
This folder contains the **ScriptoriumAI narrative companion**.
|
||||
|
||||
It includes:
|
||||
|
||||
#### `ScriptoriumAI_Volume_0.md`
|
||||
|
||||
This is the preface/rules volume for ScriptoriumAI.
|
||||
|
||||
Its job is to explain:
|
||||
|
||||
* that ScriptoriumAI is treated as largely completed
|
||||
* that latest high-value repo integrations are the focus
|
||||
* that forward planning is Claude Prism–anchored
|
||||
* that the bundle follows v6.3 truth plus later corrections
|
||||
|
||||
In plain English: this is the **interpretive framing document** for ScriptoriumAI.
|
||||
|
||||
#### `ScriptoriumAI_Volume_3.md`
|
||||
|
||||
This is the **main ScriptoriumAI repo narrative volume**.
|
||||
|
||||
It contains repos that are primarily ScriptoriumAI-first:
|
||||
|
||||
* editor/workspace/corpus/research/diagram/media/memory/publishing candidates
|
||||
* implemented surface parallels
|
||||
* latest integration candidates
|
||||
|
||||
In plain English: this is the **main ScriptoriumAI repo story**.
|
||||
|
||||
#### `ScriptoriumAI_Volume_4.md`
|
||||
|
||||
This is the **cross-project and adjacent-use volume for ScriptoriumAI**.
|
||||
|
||||
It contains repos that are not primarily ScriptoriumAI-first but still have:
|
||||
|
||||
* transfer value
|
||||
* donor value
|
||||
* reserve value
|
||||
* comparator value
|
||||
* adjacent ecosystem value
|
||||
|
||||
In plain English: this is the **extended ScriptoriumAI ecosystem layer**.
|
||||
|
||||
---
|
||||
|
||||
## The deep manual pack
|
||||
|
||||
### `v6_5_deep_manual_pack`
|
||||
|
||||
This is the **project-specific deep guidance layer**.
|
||||
|
||||
It is not a repo-by-repo portfolio.
|
||||
It is the **architectural, strategic, and implementation manual layer** for the three projects.
|
||||
|
||||
It exists because the cross-project markdowns were becoming too mixed together.
|
||||
|
||||
Inside it, each project has its own full manual set.
|
||||
|
||||
---
|
||||
|
||||
### `v6_5_deep_manual_pack/README.md`
|
||||
|
||||
This is the **master explanation of the v6.5 manual pack**.
|
||||
|
||||
It tells you:
|
||||
|
||||
* what the pack is for
|
||||
* what corrections it preserves
|
||||
* how it relates to v6.3
|
||||
* what its authority level is
|
||||
* what the project folders contain
|
||||
|
||||
In plain English: this is the **intro page for the deep manual pack**.
|
||||
|
||||
---
|
||||
|
||||
## Inside each project folder in `v6_5_deep_manual_pack`
|
||||
|
||||
Each project has the same file structure, but the meaning is project-specific.
|
||||
|
||||
---
|
||||
|
||||
### `AGENTS.md`
|
||||
|
||||
This is the **execution and behavioral guide** for models or engineers working on that specific project.
|
||||
|
||||
It explains:
|
||||
|
||||
* what the project really is
|
||||
* what must not be confused
|
||||
* what the authority order is
|
||||
* how to think when making decisions
|
||||
* what the hard directives are
|
||||
* what a coding model should and should not do
|
||||
|
||||
In plain English: this is the **project operating doctrine**.
|
||||
|
||||
---
|
||||
|
||||
### `SKILLS.md`
|
||||
|
||||
This is the **competency and work-product guide**.
|
||||
|
||||
It explains:
|
||||
|
||||
* what kind of skills a coding model needs for that project
|
||||
* what kinds of outputs it should produce
|
||||
* what kinds of repo analyses are expected
|
||||
* what the relevant technical literacies are
|
||||
|
||||
In plain English: this is the **“what a model or engineer must be good at for this project” file**.
|
||||
|
||||
---
|
||||
|
||||
### `ARCHITECTURE.md`
|
||||
|
||||
This is the **project architecture vision and system decomposition file**.
|
||||
|
||||
It explains:
|
||||
|
||||
* the project’s identity
|
||||
* runtime center
|
||||
* subsystem model
|
||||
* language posture
|
||||
* service boundaries
|
||||
* how the whole system should be assembled
|
||||
* what belongs in the backbone and what does not
|
||||
|
||||
In plain English: this is the **high-level system design file**.
|
||||
|
||||
---
|
||||
|
||||
### `API.md`
|
||||
|
||||
This is the **interface and service-boundary file**.
|
||||
|
||||
It explains:
|
||||
|
||||
* what kinds of APIs the project should expose
|
||||
* what the main API families are
|
||||
* what belongs in runtime vs service layer
|
||||
* what the transport posture is
|
||||
* how to think about interface design for that project
|
||||
|
||||
In plain English: this is the **service contract and boundary philosophy file**.
|
||||
|
||||
---
|
||||
|
||||
### `DEVELOPMENT.md`
|
||||
|
||||
This is the **implementation workflow file**.
|
||||
|
||||
It explains:
|
||||
|
||||
* how development should proceed
|
||||
* suggested repo layout
|
||||
* phase order
|
||||
* testing expectations
|
||||
* migration posture
|
||||
* coding-model handoff logic
|
||||
* build philosophy
|
||||
|
||||
In plain English: this is the **how-to-build-the-project file**.
|
||||
|
||||
---
|
||||
|
||||
### `PRD.md`
|
||||
|
||||
This is the **product requirements / product definition file**.
|
||||
|
||||
It explains:
|
||||
|
||||
* what the product is
|
||||
* who it is for
|
||||
* what problems it solves
|
||||
* what the main feature families are
|
||||
* what success looks like
|
||||
* what the product’s promise is
|
||||
|
||||
In plain English: this is the **“what product are we actually making?” file**.
|
||||
|
||||
---
|
||||
|
||||
### `LICENSETRACKING.md`
|
||||
|
||||
This is the **project-level license strategy file**.
|
||||
|
||||
It does not usually replace the row-level truth in the portfolio CSVs.
|
||||
Instead, it explains the **license decision framework** for that project:
|
||||
|
||||
* as-is
|
||||
* sidecar
|
||||
* reverse engineer
|
||||
* pattern-only
|
||||
* what to watch
|
||||
* what needs review
|
||||
|
||||
In plain English: this is the **project’s license and incorporation policy file**.
|
||||
|
||||
---
|
||||
|
||||
### `ROADMAP.md`
|
||||
|
||||
This is the **project phase and milestone file**.
|
||||
|
||||
It explains:
|
||||
|
||||
* what order major work should happen in
|
||||
* what the milestones are
|
||||
* what each phase means
|
||||
* what should be frozen first
|
||||
* what gets implemented next
|
||||
|
||||
In plain English: this is the **project sequencing file**.
|
||||
|
||||
---
|
||||
|
||||
## How all of these fit together
|
||||
|
||||
Here is the simplest way to think about the whole set:
|
||||
|
||||
### Layer 1 — master portfolio truth
|
||||
|
||||
These are the files that decide **what each repo is** and **how it currently stands**:
|
||||
|
||||
* `phase_g`
|
||||
* `operational`
|
||||
* `source_audit`
|
||||
* `vscode_packets`
|
||||
* `copyleft_strategy`
|
||||
* `re_layer`
|
||||
* `merger_matrix`
|
||||
* `cluster_narratives`
|
||||
|
||||
This layer answers:
|
||||
|
||||
* what repo is this
|
||||
* how important is it
|
||||
* what project is it for
|
||||
* how should it be used
|
||||
* what should be audited first
|
||||
|
||||
---
|
||||
|
||||
### Layer 2 — narrative interpretation
|
||||
|
||||
These are the narrative bundles:
|
||||
|
||||
* `vectorshell_narrative_bundle_v1`
|
||||
* `hypertwist_narrative_bundle_v1`
|
||||
* `scriptoriumai_narrative_bundle_v1`
|
||||
|
||||
This layer answers:
|
||||
|
||||
* what does the portfolio mean in readable prose
|
||||
* what is the story of the repos for each project
|
||||
* what is core vs adjacent
|
||||
|
||||
---
|
||||
|
||||
### Layer 3 — project manuals
|
||||
|
||||
This is the `v6_5_deep_manual_pack`.
|
||||
|
||||
This layer answers:
|
||||
|
||||
* what is the architecture of each project
|
||||
* how should it be built
|
||||
* what is the product
|
||||
* how should licenses be handled
|
||||
* how should work be sequenced
|
||||
|
||||
---
|
||||
|
||||
## If you want the shortest practical summary
|
||||
|
||||
### Use these first when a model starts fresh
|
||||
|
||||
* `repo_portfolio_unified_v6_3_README.txt`
|
||||
* `repo_portfolio_unified_branch_seed_prompt_v6_3.md`
|
||||
* `repo_portfolio_unified_consolidation_and_init_prompt_v6_3.md`
|
||||
|
||||
### Use these to decide what a repo is
|
||||
|
||||
* `repo_portfolio_unified_phase_g_v6_3.csv`
|
||||
* `repo_portfolio_unified_operational_v6_3.csv`
|
||||
|
||||
### Use these to inspect source repos in VS Code
|
||||
|
||||
* `repo_portfolio_unified_source_audit_v6_3.csv`
|
||||
* `repo_portfolio_unified_vscode_packets_v6_3.csv`
|
||||
|
||||
### Use these to reason about combinations and licensing
|
||||
|
||||
* `repo_portfolio_unified_merger_matrix_v6_3.csv`
|
||||
* `repo_portfolio_unified_copyleft_strategy_matrix_v6_3.csv`
|
||||
* `repo_portfolio_unified_re_layer_matrix_v6_3.csv`
|
||||
|
||||
### Use these to think in prose by project
|
||||
|
||||
* the three narrative bundle folders
|
||||
|
||||
### Use these to build the projects
|
||||
|
||||
* `v6_5_deep_manual_pack/*`
|
||||
|
||||
---
|
||||
|
||||
Meta
|
||||
|
||||
v6.3 & v6.5 Final Source of Truth Pack
|
||||
Date: 2026-04-21
|
||||
|
||||
Core data counts:
|
||||
{
|
||||
"operational_rows": 13603,
|
||||
"phase_g_rows": 13603,
|
||||
"source_audit_rows": 13571,
|
||||
"vscode_packets_rows": 313,
|
||||
"merger_rows": 36361,
|
||||
"cluster_rows": 35,
|
||||
"copyleft_rows": 13603,
|
||||
"re_rows": 50
|
||||
}
|
||||
|
||||
Recommended use:
|
||||
1. Freeze v6.3 & v6.5 as canonical source of truth.
|
||||
2. Use other models only as secondary source-audit contributors after they read the v6.3 docs.
|
||||
3. Generate narrative companion volumes from v6.3 & v6.5, not from older packs.
|
||||
13
docs/repo_portfolio_unified_vscode_packets_v6_3.csv
Normal file
13
docs/repo_portfolio_unified_vscode_packets_v6_3.csv
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
"packet_id","title","scope","top_repos_in_packet","primary_goal_for_coding_model","what_to_extract_first","decision_questions","required_outputs","grading_rubric","paste_ready_instruction","packet_scope_type","project_context","source_of_truth","repo","repo_key","scriptorium_bucket","source_audit_priority","current_reality_status","packet_prompt","must_inspect","integration_path","repurpose_path","merger_partner_1","merger_partner_2","merger_partner_3","success_condition","warning","_repo_norm","v6_source_of_truth","copyleft_strategy_layer_v6_1","copyleft_packet_note_v6_1","v6_3_source_of_truth"
|
||||
"HT_browser_support","HyperTwist Browser Support Stack","Lower-level browser support utilities and package-level lanes beneath the main browser surface anchors: render substrates, helper layers, QA harnesses, motion internals, state and gesture utilities, docs/demo tooling, and selected fixture packs.","ecomfe/zrender | KhronosGroup/glTF-Sample-Renderer | pmndrs/zustand | pmndrs/use-gesture | @react-spring/core | pissang/claygl | pissang/clay-viewer | google/model-viewer/packages/space-opera | google/model-viewer/packages/render-fidelity-tools | google/model-viewer/packages/model-viewer-effects | google/model-viewer/packages/modelviewer.dev | google/model-viewer/packages/shared-assets | pmndrs/react-postprocessing | pmndrs/three-stdlib | pmndrs/maath | pmndrs/leva | @react-spring/parallax | @react-spring/rafz | @react-spring/animated | @react-spring/shared | @react-spring/types","Identify the strongest lower-level browser support stack for HyperTwist beneath the already-chosen browser surface anchors.","Render substrates, QA harnesses, helper abstractions, docs/demo tooling, state and gesture utilities, motion internals, and any boundary-sensitive asset-fixture packs.","Which packages deserve direct dependency use, which should stay merge-bounded, and which are valuable mainly as support utilities rather than product-level lanes?","module map; dependency versus merge recommendation; retained support stack; notable risks or boundary constraints","Prefer lower-level utilities that materially reduce implementation cost without distorting the Unreal-first runtime direction or overgrowing the browser companion stack.","Audit cluster HT_browser_support for HyperTwist. Candidate repos: ecomfe/zrender | KhronosGroup/glTF-Sample-Renderer | pmndrs/zustand | pmndrs/use-gesture | @react-spring/core | pissang/claygl | pissang/clay-viewer | google/model-viewer/packages/space-opera | google/model-viewer/packages/render-fidelity-tools | google/model-viewer/packages/model-viewer-effects | google/model-viewer/packages/modelviewer.dev | google/model-viewer/packages/shared-assets | pmndrs/react-postprocessing | pmndrs/three-stdlib | pmndrs/maath | pmndrs/leva | @react-spring/parallax | @react-spring/rafz | @react-spring/animated | @react-spring/shared | @react-spring/types. Determine which support utilities deserve direct dependency use, bounded merge use, or narrow reference status.","HyperTwist cluster packet","HyperTwist / browser-side support utilities","Backfilled from canonized Markdown dossier pass on 2026-04-25.","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Respect each repo row in the v6.3 legal columns before recommending direct use. Most repos in these packets are permissive utility layers, but mixed or commercial rows still require bounded usage.","Default posture here is dependency use or bounded merge. Do not assume the whole upstream shell should be inherited.","v6.3_markdown_backfill"
|
||||
"HT_browser_surface","HyperTwist Browser Surface Stack","Browser-side companion stack for analytics, 3D presentation, XR interaction, spatial UI, and embodied coach surfaces.","mrdoob/three.js | pmndrs/react-three-fiber | pmndrs/xr | pmndrs/uikit | google/model-viewer | apache/echarts | met4citizen/TalkingHead | KhronosGroup/glTF-Sample-Viewer | ecomfe/echarts-gl | pmndrs/drei | pmndrs/postprocessing | pmndrs/react-spring","Identify the strongest browser-side companion stack for HyperTwist across 3D presentation, analytics, XR interaction, spatial UI, and embodied coach surfaces.","Browser 3D substrate, XR and spatial UI seams, analytics/reporting surfaces, embodied coach presentation seams, and the highest-leverage helper layers.","Which repo should anchor browser 3D? Which repo should anchor browser XR and spatial UI? Which repos are direct dependency substrates versus merge candidates or concept-only helpers?","module map; retained browser-side stack recommendation; dependency versus merge-boundary recommendation; major risks; pairing order","Prefer bounded companion-surface leverage, clean dependency or merge seams, and browser-side reuse that does not distort the Unreal-first runtime direction.","Audit cluster HT_browser_surface for HyperTwist. Candidate repos: mrdoob/three.js | pmndrs/react-three-fiber | pmndrs/xr | pmndrs/uikit | google/model-viewer | apache/echarts | met4citizen/TalkingHead | KhronosGroup/glTF-Sample-Viewer | ecomfe/echarts-gl | pmndrs/drei | pmndrs/postprocessing | pmndrs/react-spring. Determine the best browser-side companion stack for analytics, 3D presentation, XR interaction, spatial UI, and embodied coaching. Identify substrate anchors, merge candidates, and clean dependency boundaries.","HyperTwist cluster packet","HyperTwist / browser-side companion surfaces","Backfilled from canonized Markdown dossier pass on 2026-04-24.","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Before recommending direct code use, inspect repo-level v6 license and copyleft columns. These browser-side repos in this packet are permissive, but still preserve notices and treat assets separately where relevant.","Default posture in this packet is direct incorporation or bounded dependency use, not clean-room reimplementation, unless a later repo-specific exception appears.","v6.3_markdown_backfill"
|
||||
"HT_control_plane","HyperTwist Telemetry / Replay Governance","Telemetry, replay diagnostics, feature-flag governance, and control-plane donor material for HyperTwist.","PostHog/posthog","Identify the highest-value telemetry, replay, and feature-governance seams worth retaining without inheriting the broader analytics platform shell.","Replay diagnostics, replay deep links and query surfaces, feature-flag CRUD/dependency logic, event-schema design, activity logs, and service-boundary patterns.","Which surfaces should stay bounded sidecar or service-only, which MIT paths are worth direct reuse, and which ee/ or mixed-license slices should be excluded or reimplemented?","module map; boundary recommendation; reusable schemas; replay and flag-governance surfaces; mixed-license risk notes","Prefer clean control-plane seams, replay/debugging leverage, and governance utility over broad analytics-shell adoption.","Audit cluster HT_control_plane for HyperTwist. Candidate repos: PostHog/posthog. Determine the highest-value telemetry, replay diagnostics, feature-flag governance, and service-boundary seams worth retaining. Identify bounded donor surfaces, mixed-license risks, and the cleanest control-plane boundary.","HyperTwist cluster packet","HyperTwist / telemetry and replay governance","Backfilled from canonized Markdown dossier pass on 2026-04-25.","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Respect each repo row in the v6.3 legal columns before recommending direct use. Mixed-license rows require path-level review and bounded usage.","Default posture here is bounded donor use or selective reimplementation. Do not assume the analytics platform shell or any ee/ path should be inherited.","v6.3_markdown_backfill"
|
||||
"HT_cube_semantics","HyperTwist Classic Cube Semantics","Classic-cubing semantics, algorithm language, twisty playback/viewer behavior, and compact state-generation donors for HyperTwist.","cubing/cubing.js | cubing/alg.js | cubing/twisty.js | HactarCE/2x2x2x2-Scrambler","Identify the highest-value classic-cubing semantics, parser, player, and compact scrambler/state seams worth retaining without inheriting upstream shells wholesale.","Algorithm grammar and AST semantics, canonical move/state boundaries, twisty playback behavior, scrubber/viewer seams, and compact solvable-state generation logic.","Which seams should stay direct under cubing/cubing.js, which restrictive companion packages justify separate clean-room reimplementation, and what is the cleanest semantics boundary for HyperTwist?","module map; semantics boundary recommendation; reusable parser/player/state surfaces; clean-room notes for restrictive companions","Prefer canonical semantics, clean state/render boundaries, and compact reusable runtimes over broader package shells or demo surfaces.","Audit cluster HT_cube_semantics for HyperTwist. Candidate repos: cubing/cubing.js | cubing/alg.js | cubing/twisty.js | HactarCE/2x2x2x2-Scrambler. Determine the best classic-cubing semantics boundary, the retained player and state-generation seams, and which restrictive companions require separate clean-room treatment.","HyperTwist cluster packet","HyperTwist / classic-cubing semantics and supplemental runtimes","Backfilled from canonized Markdown dossier pass on 2026-04-25.","","","","P0","supplemental_v6_packet","Use v6 as the source of truth. Audit the extended HyperTwist core around logic, renderer, and puzzle-surface infrastructure. Focus on: State representations, algorithm parsers, scramblers, geometry cores, renderer abstractions, engine bindings.. Answer: Which new cubing/HactarCE repos materially deepen HyperTwist vs merely surround the existing core?.","State representations, algorithm parsers, scramblers, geometry cores, renderer abstractions, engine bindings.","HyperTwist physical + virtual hypercube training stack.","Repurpose according to v6 project design language and family role.","","","","Promotion notes, renderer/binding extraction notes, integration and merger decisions.","","","v6_unified_source_of_truth_pack","Respect each repo row in the v6.3 legal columns before recommending direct use. This packet intentionally mixes a boundary-sensitive usable anchor with restrictive clean-room companion rows.","Do not silently launder restrictive companion packages into the cubing/cubing.js lane. Keep direct-use and clean-room paths explicit.","v6.3_markdown_backfill"
|
||||
"HT_cube_vision","HyperTwist Physical Cube Vision","Extract camera calibration, cube-state reconstruction, replay, and AR handoff.","kkoomen/qbr | vivaansinghvi07/rubix-cube-solver | cahidenes/rubiks-cube-solver | tentone/rubix-solver | aMonteSl/CodeXR | brianpeiris/RiftSketch | NuiLab/code-vr | yakupbilen/drl-rubiks-cube","Identify the strongest extractable engine(s), donor modules, hidden subsystems, and merger path(s) inside the HT_cube_vision cluster.","Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.; Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.; Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.","Which repo actually owns the deepest engine? Which should remain shell-only? Which hidden modules are reusable even if the surface app is not?","module map; hidden feature list; reusable schemas; protocol/adapters; merge recommendation; estimated extraction boundary; tests/examples worth preserving","Prefer concrete internal engines, schemas, adapters, and extension hooks over README claims or surface UI appeal.","Audit cluster HT_cube_vision. Candidate repos: kkoomen/qbr | vivaansinghvi07/rubix-cube-solver | cahidenes/rubiks-cube-solver | tentone/rubix-solver | aMonteSl/CodeXR | brianpeiris/RiftSketch | NuiLab/code-vr | yakupbilen/drl-rubiks-cube. Identify base-vs-donor roles, hidden internal modules, schemas, adapter layers, plugin hooks, and the best clean-room reimplementation path.","Global cluster packet","Multi-project / global","Original global VS Code packets v3 retained","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Before recommending direct code use, inspect the target repo row in the v6.1 operational/phase/source-audit boards. Respect copyleft_strategy_v6_1, preferred_boundary_model_v6_1, and open_compliance_if_used_as_is_v6_1. Do not assume reverse engineering is mandatory or that as-is use is always sensible.","If the repo-level strategy says bounded_sidecar_preferred or boundary_first_then_decide_as_is_vs_reimplementation, audit clean interfaces, protocol seams, subprocess/container boundaries, and what would be required to reimplement only the strategically necessary portions.","v6.3_final_source_of_truth"
|
||||
"HT_hyper_engine","HyperTwist Hypercubing Engine","Extract generalized puzzle/state/render abstractions for 3D–nD puzzles.","HactarCE/Hyperspeedcube | kash/cubedesk | cutelyaware/magiccube4d | roice3/Magic120Cell | roice3/MagicCube5D | roice3/MagicTile | Hypercubers/hypercubing.xyz","Identify the strongest extractable engine(s), donor modules, hidden subsystems, and merger path(s) inside the HT_hyper_engine cluster.","Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.; Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.; Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.","Which repo actually owns the deepest engine? Which should remain shell-only? Which hidden modules are reusable even if the surface app is not?","module map; hidden feature list; reusable schemas; protocol/adapters; merge recommendation; estimated extraction boundary; tests/examples worth preserving","Prefer concrete internal engines, schemas, adapters, and extension hooks over README claims or surface UI appeal.","Audit cluster HT_hyper_engine. Candidate repos: HactarCE/Hyperspeedcube | kash/cubedesk | cutelyaware/magiccube4d | roice3/Magic120Cell | roice3/MagicCube5D | roice3/MagicTile | Hypercubers/hypercubing.xyz. Identify base-vs-donor roles, hidden internal modules, schemas, adapter layers, plugin hooks, and the best clean-room reimplementation path.","Global cluster packet","Multi-project / global","Original global VS Code packets v3 retained","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Before recommending direct code use, inspect the target repo row in the v6.1 operational/phase/source-audit boards. Respect copyleft_strategy_v6_1, preferred_boundary_model_v6_1, and open_compliance_if_used_as_is_v6_1. Do not assume reverse engineering is mandatory or that as-is use is always sensible.","If the repo-level strategy says bounded_sidecar_preferred or boundary_first_then_decide_as_is_vs_reimplementation, audit clean interfaces, protocol seams, subprocess/container boundaries, and what would be required to reimplement only the strategically necessary portions.","v6.3_final_source_of_truth"
|
||||
"HT_solver_oracles","HyperTwist Solver Oracles","Solver-oracle and benchmarking lanes for correctness, robot metrics, and larger-cube planning reference.","efrantar/rob-twophase | ShellPuppy/RCube","Identify what should remain pure oracle or benchmark behavior and whether any narrow algorithmic seam deserves later clean-room extraction.","Correctness-oracle behavior, large-N or robot-metric seams, and benchmark harness details.","What should remain benchmark-only, and are there any bounded solver or metric seams worth later clean-room reimplementation?","oracle map; benchmark surfaces; retained algorithmic seams; clean-room candidate note","Prefer correctness, benchmark value, and bounded oracle surfaces over any upstream shell adoption.","Audit cluster HT_solver_oracles for HyperTwist. Candidate repos: efrantar/rob-twophase | ShellPuppy/RCube. Determine what must remain benchmark/oracle-only and whether any narrow seam justifies later clean-room extraction.","HyperTwist cluster packet","HyperTwist / solver oracles and benchmarks","Backfilled from canonized Markdown dossier pass on 2026-04-25.","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Respect each repo row in the v6.3 legal columns before recommending direct use. These are retained mainly as benchmark/oracle rows, not donor shells.","Default posture here is benchmark use or clean-room extraction, not direct donor adoption.","v6.3_markdown_backfill"
|
||||
"HT_support_sidecars","HyperTwist Support Sidecars","Support-plane sidecars for local capture/history/replay and media export or explainer rendering.","screenpipe/screenpipe | remotion-dev/remotion","Identify the strongest support-plane sidecars for capture/history/replay and media export without letting them distort the core product architecture.","Capture and replay seams, permission-aware support tooling, media export and explainer rendering surfaces.","Which support-plane sidecars should stay outside the product core and what is the cleanest bounded deployment posture for each?","sidecar recommendation; boundary model; retained modules; licensing or deployment risks","Prefer clean sidecar boundaries, operational usefulness, and bounded leverage over broad product-shell adoption.","Audit cluster HT_support_sidecars for HyperTwist. Candidate repos: screenpipe/screenpipe | remotion-dev/remotion. Determine the best bounded support sidecars for local capture/history/replay and media export or explainer rendering. Identify the cleanest boundary model and the modules worth retaining.","HyperTwist cluster packet","HyperTwist / support-plane sidecars","Backfilled from canonized Markdown dossier pass on 2026-04-25.","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Respect each repo row in the v6.3 legal columns before recommending direct use. Most repos in these packets are permissive utility layers, but mixed or commercial rows still require bounded usage.","Default posture here is dependency use or bounded merge. Do not assume the whole upstream shell should be inherited.","v6.3_markdown_backfill"
|
||||
"HT_timer_training","HyperTwist Timer Gold Standards","Timer behavior, inspection flow, and mature stats ergonomics benchmark.","cs0x7f/cstimer","Capture the gold-standard timer behavior and edge-case handling worth preserving as a benchmark reference.","Timer-state edge cases, inspection handling, rolling stats behavior, and event sequencing details.","Which timer behaviors are canonical enough to preserve as benchmark expectations, and what should remain pure reference rather than donor code?","behavior map; benchmark expectations; edge-case list; bounded timer reference notes","Prefer precise benchmark behavior and timer-state correctness over shell adoption.","Audit cluster HT_timer_training for HyperTwist. Candidate repos: cs0x7f/cstimer. Capture the timer, inspection, and stats behaviors that should survive as benchmark expectations.","HyperTwist cluster packet","HyperTwist / timer benchmark lane","Backfilled from canonized Markdown dossier pass on 2026-04-25.","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Respect each repo row in the v6.3 legal columns before recommending direct use. This packet is benchmark-first, not donor-first.","Default posture here is benchmark/reference use or clean-room extraction if a timer seam later proves essential.","v6.3_markdown_backfill"
|
||||
"HT_training_clean_room","HyperTwist Training Clean-Room Bench","Clean-room training benchmarks and restrictive training donors beneath the main training stack.","onionhoney/roux-trainers | alinen/cube | ambisinister/blindsolve | AviKaufman/Rubix-cube-trainer | MathewKJ2048/Rubiks-cube-simulator | vwcwong/CubeSim","Identify the highest-value clean-room training and pedagogy patterns worth preserving while keeping restrictive or no-license rows out of the direct donor path.","Planner behavior, drill pacing, pedagogy scaffolds, state-history handling, blindfold memo flows, and method-specific trainer logic.","Which rows stay benchmark-only, which deserve further Model A work, and which narrow training seams justify explicit clean-room extraction?","clean-room spec map; benchmark-only list; retained pedagogy and planner seams; custody recommendations","Prefer clean-room-safe behavior extraction and narrow subsystem specs over any temptation to inherit upstream shells.","Audit cluster HT_training_clean_room for HyperTwist. Candidate repos: onionhoney/roux-trainers | alinen/cube | ambisinister/blindsolve | AviKaufman/Rubix-cube-trainer | MathewKJ2048/Rubiks-cube-simulator | vwcwong/CubeSim. Determine benchmark-only versus clean-room-donor status and the highest-value training/pedagogy seams.","HyperTwist cluster packet","HyperTwist / restrictive and clean-room training lane","Backfilled from canonized Markdown dossier pass on 2026-04-25.","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Respect each repo row in the v6.3 legal columns before recommending direct use. This packet intentionally concentrates restrictive or no-license rows that should stay benchmark-first or clean-room-only.","Default posture here is Model A analysis, clean-room spec extraction, or benchmark use. Do not propose direct adoption of these shells.","v6.3_markdown_backfill"
|
||||
"HT_training_stack","HyperTwist Training Stack","Extract trainer scheduling, timer/replay, case databases, and pedagogy UX.","tao-yu/Alg-Trainer | poliva/cubedex | Lykos/cube_trainer | abunickabhi/5style-Trainer | brownan/Rubiks-Cube-Solver | newyork-anthonyng/rubiks-cross-trainer | Aarav2709/KubeTimr","Identify the strongest extractable engine(s), donor modules, hidden subsystems, and merger path(s) inside the HT_training_stack cluster.","Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.; Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.; Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.","Which repo actually owns the deepest engine? Which should remain shell-only? Which hidden modules are reusable even if the surface app is not?","module map; hidden feature list; reusable schemas; protocol/adapters; merge recommendation; estimated extraction boundary; tests/examples worth preserving","Prefer concrete internal engines, schemas, adapters, and extension hooks over README claims or surface UI appeal.","Audit cluster HT_training_stack. Candidate repos: tao-yu/Alg-Trainer | poliva/cubedex | Lykos/cube_trainer | abunickabhi/5style-Trainer | brownan/Rubiks-Cube-Solver | newyork-anthonyng/rubiks-cross-trainer | Aarav2709/KubeTimr. Identify base-vs-donor roles, hidden internal modules, schemas, adapter layers, plugin hooks, and the best clean-room or direct-integration path for the training pillar.","Global cluster packet","Multi-project / global","Original global VS Code packets v3 retained","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Before recommending direct code use, inspect the target repo row in the v6.1 operational/phase/source-audit boards. Respect copyleft_strategy_v6_1, preferred_boundary_model_v6_1, and open_compliance_if_used_as_is_v6_1. Do not assume reverse engineering is mandatory or that as-is use is always sensible.","If the repo-level strategy says bounded_sidecar_preferred or boundary_first_then_decide_as_is_vs_reimplementation, audit clean interfaces, protocol seams, subprocess/container boundaries, and what would be required to reimplement only the strategically necessary portions.","v6.3_final_source_of_truth"
|
||||
"MU_misc","HyperTwist Voice / Coaching Stack","Bounded voice sidecars for HyperTwist coaching, spoken guidance, and local speech IO.","ggml-org/whisper.cpp | SYSTRAN/faster-whisper | rhasspy/piper | coqui-ai/TTS","Identify the strongest bounded local speech stack for HyperTwist coaching and hands-free interaction, preferring ggml-org/whisper.cpp as the native STT anchor and treating faster-whisper as the complementary Python path.","Inspect streaming pipeline; VAD/segmentation; device abstraction; latency handling; multilingual or translation chain; local/offline fallback; API wrappers.","Which repo is the best STT anchor? Which repo is the best TTS anchor? What should stay sidecar-only rather than enter the runtime core?","module map; reusable audio pipeline pieces; boundary recommendation; latency risks; recommended STT/TTS pairing","Prefer low-latency local speech paths, clean sidecar boundaries, and reusable adapters over flashy surface UX.","Audit cluster MU_misc for HyperTwist. Candidate repos: ggml-org/whisper.cpp | SYSTRAN/faster-whisper | rhasspy/piper | coqui-ai/TTS. Determine the best bounded local voice stack for coaching and hands-free interaction. Identify STT/TTS anchors, reusable modules, adapter layers, and the cleanest sidecar boundary.","HyperTwist cluster packet","HyperTwist / voice coaching sidecars","Original global VS Code packets v3 retained","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Before recommending direct code use, inspect the target repo row in the v6.1 operational/phase/source-audit boards. Respect copyleft_strategy_v6_1, preferred_boundary_model_v6_1, and open_compliance_if_used_as_is_v6_1. Do not assume reverse engineering is mandatory or that as-is use is always sensible.","If the repo-level strategy says bounded_sidecar_preferred or boundary_first_then_decide_as_is_vs_reimplementation, audit clean interfaces, protocol seams, subprocess/container boundaries, and what would be required to reimplement only the strategically necessary portions.","v6.3_final_source_of_truth"
|
||||
|
68
docs/v6_5_deep_manual_pack/HyperTwist/AGENTS.md
Normal file
68
docs/v6_5_deep_manual_pack/HyperTwist/AGENTS.md
Normal file
|
|
@ -0,0 +1,68 @@
|
|||
# HyperTwist — AGENTS.md
|
||||
|
||||
## What HyperTwist is
|
||||
|
||||
HyperTwist is the portfolio’s cube and hypercube training environment. It must preserve two identities at once:
|
||||
- a practical physical-cube recognition, replay, and coaching platform
|
||||
- a serious higher-dimensional simulation and hypercubing environment
|
||||
|
||||
It is not enough for HyperTwist to be good at only one of those.
|
||||
|
||||
## Authority order
|
||||
|
||||
1. `repo_portfolio_unified_v6_3.*`
|
||||
2. This `AGENTS.md`
|
||||
3. The rest of the HyperTwist v6.5 manual set
|
||||
4. CubeForge initial research as **inspiration only**, not as code to directly integrate
|
||||
|
||||
## Core directives
|
||||
|
||||
### Dual-pillar preservation
|
||||
Never collapse:
|
||||
- physical cube pipeline
|
||||
- hypercube simulation pipeline
|
||||
|
||||
They are parallel pillars that reinforce each other.
|
||||
|
||||
### Unreal-first posture
|
||||
HyperTwist is native-first. The main runtime should be Unreal Engine 5.4+ with:
|
||||
- C++ core systems
|
||||
- Blueprints for UX and training orchestration
|
||||
- optional OpenXR/VR/MR modes where they materially strengthen higher-dimensional learning
|
||||
|
||||
### Backbone language bias
|
||||
Prefer:
|
||||
- C++
|
||||
- Rust
|
||||
- bounded C#
|
||||
|
||||
Minimize:
|
||||
- TypeScript
|
||||
- Node.js
|
||||
- Python
|
||||
|
||||
But do not remove them where they are still the best practical host for:
|
||||
- CV/model inference
|
||||
- certain training or ingestion helpers
|
||||
- thin companion UIs
|
||||
|
||||
## Repo classification lens
|
||||
|
||||
HyperTwist repos should be judged in these families:
|
||||
- hypercube simulation foundations
|
||||
- 3D twisty-puzzle foundations
|
||||
- physical-cube recognition
|
||||
- replay and solve analytics
|
||||
- training and curriculum
|
||||
- coaching and personalization
|
||||
- immersive rendering / XR
|
||||
- export and progression
|
||||
|
||||
## Coding-model duties
|
||||
|
||||
For any HyperTwist repo, the coding model must determine:
|
||||
- what is truly implemented
|
||||
- whether it strengthens the physical pipeline, the hyper pipeline, or both
|
||||
- whether it belongs natively in the runtime, in a sidecar, or only as donor logic
|
||||
- whether it should be treated as foundation, strategic donor, reserve, or comparator
|
||||
- whether additional org/index harvesting is still worthwhile
|
||||
42
docs/v6_5_deep_manual_pack/HyperTwist/API.md
Normal file
42
docs/v6_5_deep_manual_pack/HyperTwist/API.md
Normal file
|
|
@ -0,0 +1,42 @@
|
|||
# HyperTwist — API.md
|
||||
|
||||
## API philosophy
|
||||
|
||||
HyperTwist should use APIs to support the native runtime, not to replace it.
|
||||
The system should remain primarily native-first and local-first where reasonable.
|
||||
|
||||
## Main API families
|
||||
|
||||
### Recognition API
|
||||
- frame ingestion
|
||||
- facelet/state detection
|
||||
- confidence reporting
|
||||
- corrective suggestions
|
||||
|
||||
### Replay API
|
||||
- replay storage and export
|
||||
- solve timeline annotations
|
||||
- AI-commentary attachment
|
||||
|
||||
### Coaching API
|
||||
- drill recommendations
|
||||
- progression updates
|
||||
- error clustering
|
||||
- personalized next-step guidance
|
||||
|
||||
### Profile / progression API
|
||||
- user settings
|
||||
- training history
|
||||
- unlocked modules
|
||||
- performance metrics
|
||||
|
||||
### Curriculum API
|
||||
- guided lesson packets
|
||||
- method ladders
|
||||
- hyper-specific modules
|
||||
- school or educational variants if later needed
|
||||
|
||||
## Deployment posture
|
||||
|
||||
Keep local computation local where sensible.
|
||||
Do not server-centralize everything just because an HTTP interface can be drawn.
|
||||
113
docs/v6_5_deep_manual_pack/HyperTwist/ARCHITECTURE.md
Normal file
113
docs/v6_5_deep_manual_pack/HyperTwist/ARCHITECTURE.md
Normal file
|
|
@ -0,0 +1,113 @@
|
|||
# HyperTwist — ARCHITECTURE.md
|
||||
|
||||
## Product identity
|
||||
|
||||
HyperTwist is an all-in-one native training environment for cubes and hypercubes. Its special strength is that it joins:
|
||||
- physical-world cube interaction and analysis
|
||||
- virtual simulation and higher-dimensional training
|
||||
- AI-guided coaching and progression
|
||||
|
||||
## Runtime center
|
||||
|
||||
The runtime center should be Unreal Engine 5.4+.
|
||||
|
||||
### Why Unreal fits
|
||||
Unreal is justified because HyperTwist is not merely a trainer app. It wants:
|
||||
- high-quality rendering
|
||||
- immersive puzzle manipulation
|
||||
- spatial intuition for higher dimensions
|
||||
- VR/MR expansion potential
|
||||
- high-performance native runtime
|
||||
|
||||
## Backbone language strategy
|
||||
|
||||
### C++
|
||||
Use for:
|
||||
- puzzle-state core
|
||||
- renderer integration
|
||||
- interaction hot paths
|
||||
- replay engine
|
||||
- native timer and analytics primitives
|
||||
- projection logic
|
||||
- heavy simulation work
|
||||
|
||||
### Rust or C++
|
||||
Use for:
|
||||
- algorithm engines
|
||||
- search and scoring
|
||||
- state serialization
|
||||
- progression computations
|
||||
- high-throughput replay or analytics pipelines
|
||||
|
||||
### C#
|
||||
Use only where:
|
||||
- bounded profile/progression/orchestration services
|
||||
- enterprise or educational admin surfaces
|
||||
- durable background jobs
|
||||
are clearly beneficial
|
||||
|
||||
### Python / TypeScript
|
||||
Keep bounded:
|
||||
- Python for CV or model inference where still practical
|
||||
- TypeScript for thin dashboard or companion UI surfaces only
|
||||
|
||||
## Dual-pillar architecture
|
||||
|
||||
### Pillar 1 — physical cube pipeline
|
||||
- camera input
|
||||
- state recognition
|
||||
- confidence and correction UI
|
||||
- solve reconstruction
|
||||
- replay generation
|
||||
- AI commentary and drill suggestions
|
||||
|
||||
### Pillar 2 — hypercube simulation pipeline
|
||||
- n-dimensional puzzle model
|
||||
- rendering and projection
|
||||
- notation teaching
|
||||
- immersive manipulation
|
||||
- advanced user workflows
|
||||
- compatibility with known hypercubing formats where worthwhile
|
||||
|
||||
## Subsystem proposal
|
||||
|
||||
- `HyperTwistCore`
|
||||
- `HyperTwistSimulation`
|
||||
- `HyperTwistRecognition`
|
||||
- `HyperTwistReplay`
|
||||
- `HyperTwistTraining`
|
||||
- `HyperTwistCoach`
|
||||
- `HyperTwistProgression`
|
||||
- `HyperTwistXR`
|
||||
|
||||
## Integration policy
|
||||
|
||||
### Foundation candidates
|
||||
Treat true simulation cores and essential logic frameworks separately from:
|
||||
- wrappers
|
||||
- ports
|
||||
- UI frameworks
|
||||
- ecosystem experiments
|
||||
|
||||
### CV candidates
|
||||
Likely best as bounded services or donor modules first unless one is simple and directly embeddable.
|
||||
|
||||
### Trainer candidates
|
||||
Often strategic donors rather than foundations.
|
||||
|
||||
### Hyper tools
|
||||
Need to be judged for:
|
||||
- algorithmic depth
|
||||
- notation compatibility
|
||||
- rendering value
|
||||
- interoperability with the rest of the stack
|
||||
|
||||
## Unreal/XR posture
|
||||
|
||||
HyperTwist benefits from:
|
||||
- controller and hand-based manipulation
|
||||
- spatial coaching overlays
|
||||
- higher-dimensional explanatory projection
|
||||
- embodied replay and algorithm walkthroughs
|
||||
|
||||
The immersive mode is not the whole product, but it is a major differentiator.
|
||||
50
docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md
Normal file
50
docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md
Normal file
|
|
@ -0,0 +1,50 @@
|
|||
# HyperTwist — DEVELOPMENT.md
|
||||
|
||||
## Development philosophy
|
||||
|
||||
HyperTwist should be developed as a serious native product:
|
||||
- Unreal project as the main runtime
|
||||
- C++ simulation and rendering core
|
||||
- Blueprints for interaction and curriculum logic
|
||||
- bounded CV or analytics sidecars where needed
|
||||
- minimal web-only surface
|
||||
|
||||
## Suggested repo structure
|
||||
|
||||
- `HyperTwist/`
|
||||
- `Source/HyperTwistCore`
|
||||
- `Source/HyperTwistSimulation`
|
||||
- `Source/HyperTwistRecognition`
|
||||
- `Source/HyperTwistReplay`
|
||||
- `Source/HyperTwistTraining`
|
||||
- `Source/HyperTwistCoach`
|
||||
- `Source/HyperTwistXR`
|
||||
- `hypertwist-services/`
|
||||
- optional CV inference service
|
||||
- optional progression or coaching service
|
||||
- `docs/`
|
||||
- replay packet specs
|
||||
- trainer logic
|
||||
- notation / interchange specs
|
||||
- benchmark notes
|
||||
|
||||
## Build order
|
||||
|
||||
1. simulation core
|
||||
2. state and notation standardization
|
||||
3. replay and export
|
||||
4. physical recognition
|
||||
5. trainer/progression
|
||||
6. AI coach
|
||||
7. immersive hyper modes
|
||||
8. optimization and polish
|
||||
|
||||
## Testing
|
||||
|
||||
- move/state correctness
|
||||
- replay integrity
|
||||
- scramble validity
|
||||
- CV uncertainty handling
|
||||
- coaching recommendation stability
|
||||
- XR interaction reliability
|
||||
- progression persistence and analytics
|
||||
24
docs/v6_5_deep_manual_pack/HyperTwist/LICENSETRACKING.md
Normal file
24
docs/v6_5_deep_manual_pack/HyperTwist/LICENSETRACKING.md
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
# HyperTwist — LICENSETRACKING.md
|
||||
|
||||
## Project policy
|
||||
|
||||
Every repo should be judged as:
|
||||
- incorporate as-is
|
||||
- bounded sidecar
|
||||
- reverse engineer
|
||||
- pattern-only
|
||||
|
||||
## Family-specific guidance
|
||||
|
||||
### Simulation foundations
|
||||
Direct use can be sensible if the engine is excellent and the obligations are acceptable.
|
||||
Reverse engineering is cleaner if deep proprietary/native integration is the true goal.
|
||||
|
||||
### CV and coaching
|
||||
Often best as bounded services, donor modules, or selective reimplementations.
|
||||
|
||||
### Trainers and timers
|
||||
These are often strategic donors or comparators rather than foundations.
|
||||
|
||||
### Hyper ecosystems
|
||||
Treat carefully. Some repos matter historically or educationally even when they are not operational foundations.
|
||||
39
docs/v6_5_deep_manual_pack/HyperTwist/PRD.md
Normal file
39
docs/v6_5_deep_manual_pack/HyperTwist/PRD.md
Normal file
|
|
@ -0,0 +1,39 @@
|
|||
# HyperTwist — PRD.md
|
||||
|
||||
## Product definition
|
||||
|
||||
HyperTwist is a native cube and hypercube training environment that combines recognition, replay, simulation, coaching, and immersive instruction.
|
||||
|
||||
## Users
|
||||
|
||||
- beginners learning 3D solving
|
||||
- intermediate and advanced cubers
|
||||
- hypercubers
|
||||
- educators
|
||||
- content creators
|
||||
- self-directed AI-assisted learners
|
||||
|
||||
## Core problems solved
|
||||
|
||||
- weak solve analysis in existing tools
|
||||
- separation between physical practice and virtual analysis
|
||||
- insufficient serious support for higher-dimensional practice
|
||||
- fragmented training, timing, simulation, and replay tools
|
||||
|
||||
## Core feature families
|
||||
|
||||
- physical cube recognition
|
||||
- solve reconstruction and replay
|
||||
- algorithm and drill training
|
||||
- AI coaching
|
||||
- hypercube simulation
|
||||
- progression and analytics
|
||||
- immersive training
|
||||
- export and sharing
|
||||
|
||||
## Success criteria
|
||||
|
||||
- users measurably improve faster
|
||||
- higher-dimensional users take the platform seriously
|
||||
- the physical and virtual pillars reinforce each other
|
||||
- the product feels native, polished, and coherent
|
||||
37
docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md
Normal file
37
docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md
Normal file
|
|
@ -0,0 +1,37 @@
|
|||
# HyperTwist — ROADMAP.md
|
||||
|
||||
## A — Alignment
|
||||
Freeze terminology, repo roles, and dual-pillar architecture.
|
||||
|
||||
## B — Base simulation runtime
|
||||
Stand up Unreal runtime, puzzle-state core, and core rendering loop.
|
||||
|
||||
## C — Cube-state / notation layer
|
||||
Standardize notation, scramble, replay packets, and interchange.
|
||||
|
||||
## D — Detection and reconstruction
|
||||
Integrate camera/CV and confidence-aware reconstruction.
|
||||
|
||||
## E — Replay and explainability
|
||||
Build replay surfaces, timing analysis, and explanatory overlays.
|
||||
|
||||
## F — Foundational training
|
||||
Drills, timers, analytics, curriculum, and method-aware progression.
|
||||
|
||||
## G — General AI coach
|
||||
Commentary, drill planning, and personalized progression support.
|
||||
|
||||
## H — Hyper engine deepening
|
||||
Expand higher-dimensional support, projection, and advanced workflows.
|
||||
|
||||
## I — Immersive interaction
|
||||
XR modes, puzzle manipulation, and spatial tutorial flows.
|
||||
|
||||
## J — Validation and benchmarking
|
||||
Correctness, replay integrity, performance, and benchmark harnesses.
|
||||
|
||||
## K — Knowledge and curriculum
|
||||
Guided ladders from beginner through hypercubing expertise.
|
||||
|
||||
## L–Z
|
||||
Continue event expansion, export, community-facing surfaces, optimization, enterprise/education variants, and release hardening.
|
||||
52
docs/v6_5_deep_manual_pack/HyperTwist/SKILLS.md
Normal file
52
docs/v6_5_deep_manual_pack/HyperTwist/SKILLS.md
Normal file
|
|
@ -0,0 +1,52 @@
|
|||
# HyperTwist — SKILLS.md
|
||||
|
||||
## Core competencies
|
||||
|
||||
A coding model working on HyperTwist must be able to:
|
||||
- inspect simulation engines
|
||||
- understand move/state notation
|
||||
- inspect replay and trainer code
|
||||
- inspect CV recognition stacks
|
||||
- reason about user progression systems
|
||||
- distinguish educational UX from simulation correctness
|
||||
- propose Unreal-native implementation paths
|
||||
|
||||
## Work products
|
||||
|
||||
For each meaningful repo or subsystem, produce:
|
||||
- capability summary
|
||||
- integration mode
|
||||
- training value
|
||||
- coaching value
|
||||
- performance implications
|
||||
- whether it belongs to physical or hyper pipeline
|
||||
- what would justify native integration vs sidecar use
|
||||
|
||||
## Domain skills
|
||||
|
||||
### Simulation
|
||||
- move representation
|
||||
- scramble generation
|
||||
- solver or state engine analysis
|
||||
- replay model design
|
||||
- notation and interoperability
|
||||
|
||||
### Recognition
|
||||
- camera assumptions
|
||||
- color classification
|
||||
- uncertainty handling
|
||||
- state reconstruction
|
||||
- performance and device assumptions
|
||||
|
||||
### Training
|
||||
- spaced or repeated practice logic
|
||||
- progression systems
|
||||
- analytics
|
||||
- curriculum scaffolds
|
||||
- personalized recommendations
|
||||
|
||||
### Immersion
|
||||
- Unreal scene management
|
||||
- puzzle manipulation
|
||||
- XR interactions
|
||||
- projection and explanatory overlays
|
||||
27
docs/v6_5_deep_manual_pack/README.md
Normal file
27
docs/v6_5_deep_manual_pack/README.md
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
# v6.5 Deep Manual Pack
|
||||
|
||||
This pack expands the split v6.4 docs into a more exhaustive project-specific manual set.
|
||||
|
||||
## Core corrections preserved
|
||||
- The latest attachment used for VectorShell / HyperTwist is treated as **inspiration**, not as code to be directly integrated.
|
||||
- ScriptoriumAI is treated as **mostly completed** and **Claude Prism–anchored** for active planning.
|
||||
- Overleaf-centered active guidance is retired from this pack.
|
||||
- Unreal Engine 5.4+, C++, Blueprints, OpenXR, and a Rust/C#/C++ backbone bias are explicit for VectorShell and HyperTwist.
|
||||
- TypeScript, Node.js, and Python are minimized in backbone planning, but not omitted where they remain the most practical choice.
|
||||
- Repo-level license truth still lives in the portfolio CSVs. These manuals set architecture, execution, and policy.
|
||||
|
||||
## Authority order
|
||||
1. `repo_portfolio_unified_v6_3.*` and companion matrices remain repo-row source of truth
|
||||
2. This v6.5 deep manual pack governs project-level architecture and implementation posture
|
||||
3. v6.4 and earlier project markdowns are lineage and rollback reference only
|
||||
|
||||
## Project folders
|
||||
Each project contains:
|
||||
- AGENTS.md
|
||||
- SKILLS.md
|
||||
- ARCHITECTURE.md
|
||||
- API.md
|
||||
- DEVELOPMENT.md
|
||||
- PRD.md
|
||||
- LICENSETRACKING.md
|
||||
- ROADMAP.md
|
||||
BIN
logo/HyperTwist logo with 3D symbol.png
Normal file
BIN
logo/HyperTwist logo with 3D symbol.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 2.1 MiB |
792
scripts/Initialize-ExternalProductWorkspace.ps1
Normal file
792
scripts/Initialize-ExternalProductWorkspace.ps1
Normal file
|
|
@ -0,0 +1,792 @@
|
|||
[CmdletBinding()]
|
||||
param(
|
||||
[ValidateSet('All', 'ScriptoriumAI', 'HyperTwist', 'VectorShell')]
|
||||
[string]$Product = 'All',
|
||||
[string]$WorkspaceBase = 'C:\Workspaces',
|
||||
[switch]$ForceManifestRefresh
|
||||
)
|
||||
|
||||
Set-StrictMode -Version Latest
|
||||
$ErrorActionPreference = 'Stop'
|
||||
|
||||
function New-StableGuid {
|
||||
param([Parameter(Mandatory = $true)][string]$InputString)
|
||||
|
||||
$bytes = [System.Text.Encoding]::UTF8.GetBytes($InputString.ToLowerInvariant())
|
||||
$md5 = [System.Security.Cryptography.MD5]::Create()
|
||||
try {
|
||||
$hash = $md5.ComputeHash($bytes)
|
||||
} finally {
|
||||
$md5.Dispose()
|
||||
}
|
||||
|
||||
$hex = ($hash | ForEach-Object { $_.ToString('x2') }) -join ''
|
||||
$guidText = '{0}-{1}-{2}-{3}-{4}' -f $hex.Substring(0, 8), $hex.Substring(8, 4), $hex.Substring(12, 4), $hex.Substring(16, 4), $hex.Substring(20, 12)
|
||||
return "{${guidText}}".ToUpperInvariant()
|
||||
}
|
||||
|
||||
function Ensure-Directory {
|
||||
param([Parameter(Mandatory = $true)][string]$Path)
|
||||
|
||||
if (-not (Test-Path -LiteralPath $Path)) {
|
||||
New-Item -ItemType Directory -Path $Path | Out-Null
|
||||
}
|
||||
}
|
||||
|
||||
function Write-Utf8File {
|
||||
param(
|
||||
[Parameter(Mandatory = $true)][string]$Path,
|
||||
[Parameter(Mandatory = $true)][AllowEmptyString()][string[]]$Lines
|
||||
)
|
||||
|
||||
$parent = Split-Path -Path $Path -Parent
|
||||
if ($parent) {
|
||||
Ensure-Directory -Path $parent
|
||||
}
|
||||
|
||||
[System.IO.File]::WriteAllLines($Path, $Lines, [System.Text.UTF8Encoding]::new($false))
|
||||
}
|
||||
|
||||
function New-RelativePath {
|
||||
param(
|
||||
[Parameter(Mandatory = $true)][string]$BasePath,
|
||||
[Parameter(Mandatory = $true)][string]$TargetPath
|
||||
)
|
||||
|
||||
$baseResolved = (Resolve-Path -LiteralPath $BasePath).Path.TrimEnd('\') + '\'
|
||||
$targetResolved = (Resolve-Path -LiteralPath $TargetPath).Path
|
||||
$baseUri = [System.Uri]$baseResolved
|
||||
$targetUri = [System.Uri]$targetResolved
|
||||
$relativeUri = $baseUri.MakeRelativeUri($targetUri)
|
||||
return [System.Uri]::UnescapeDataString($relativeUri.ToString()).Replace('/', '\')
|
||||
}
|
||||
|
||||
function New-MirrorPath {
|
||||
param(
|
||||
[Parameter(Mandatory = $true)][string]$MirrorRoot,
|
||||
[Parameter(Mandatory = $true)][string]$Owner,
|
||||
[Parameter(Mandatory = $true)][string]$Repo
|
||||
)
|
||||
|
||||
return Join-Path (Join-Path $MirrorRoot $Owner) $Repo
|
||||
}
|
||||
|
||||
function New-RepositoryEntry {
|
||||
param(
|
||||
[Parameter(Mandatory = $true)][string]$Key,
|
||||
[Parameter(Mandatory = $true)][string]$Name,
|
||||
[string]$RepoUrl,
|
||||
[Parameter(Mandatory = $true)][string]$LocalPath,
|
||||
[Parameter(Mandatory = $true)][string]$Purpose,
|
||||
[Parameter(Mandatory = $true)][string]$Language,
|
||||
[Parameter(Mandatory = $true)][string]$IncludeMode,
|
||||
[Parameter(Mandatory = $true)][string]$Storage,
|
||||
[bool]$Active = $true,
|
||||
[object[]]$ProjectFiles = @(),
|
||||
[string]$License = '',
|
||||
[string]$LicenseStatus = '',
|
||||
[string]$MirrorClass = '',
|
||||
[string]$WorkflowRole = '',
|
||||
[bool]$ModelAAllowedSourceAccess = $true,
|
||||
[bool]$ModelBAllowedSourceAccess = $true,
|
||||
[string]$HandoffDoc = '',
|
||||
[string[]]$Notes = @()
|
||||
)
|
||||
|
||||
return [ordered]@{
|
||||
key = $Key
|
||||
name = $Name
|
||||
repoUrl = $RepoUrl
|
||||
localPath = $LocalPath
|
||||
purpose = $Purpose
|
||||
language = $Language
|
||||
includeMode = $IncludeMode
|
||||
storage = $Storage
|
||||
active = $Active
|
||||
projectFiles = $ProjectFiles
|
||||
license = $License
|
||||
licenseStatus = $LicenseStatus
|
||||
mirrorClass = $MirrorClass
|
||||
workflowRole = $WorkflowRole
|
||||
modelAAllowedSourceAccess = $ModelAAllowedSourceAccess
|
||||
modelBAllowedSourceAccess = $ModelBAllowedSourceAccess
|
||||
handoffDoc = $HandoffDoc
|
||||
notes = $Notes
|
||||
}
|
||||
}
|
||||
|
||||
function New-ExternalMirrorEntry {
|
||||
param(
|
||||
[Parameter(Mandatory = $true)][string]$Key,
|
||||
[Parameter(Mandatory = $true)][string]$Name,
|
||||
[Parameter(Mandatory = $true)][string]$RepoUrl,
|
||||
[Parameter(Mandatory = $true)][string]$MirrorRoot,
|
||||
[Parameter(Mandatory = $true)][string]$Owner,
|
||||
[Parameter(Mandatory = $true)][string]$Repo,
|
||||
[Parameter(Mandatory = $true)][string]$Purpose,
|
||||
[Parameter(Mandatory = $true)][string]$Language,
|
||||
[Parameter(Mandatory = $true)][string]$License,
|
||||
[Parameter(Mandatory = $true)][string]$LicenseStatus,
|
||||
[Parameter(Mandatory = $true)][string]$MirrorClass,
|
||||
[Parameter(Mandatory = $true)][string]$WorkflowRole,
|
||||
[string]$HandoffDoc = '',
|
||||
[string[]]$Notes = @(),
|
||||
[bool]$Active = $true
|
||||
)
|
||||
|
||||
$localPath = New-MirrorPath -MirrorRoot $MirrorRoot -Owner $Owner -Repo $Repo
|
||||
$modelBAllowed = $true
|
||||
if ($MirrorClass -eq 'restrictive') {
|
||||
$modelBAllowed = $false
|
||||
}
|
||||
|
||||
return New-RepositoryEntry -Key $Key -Name $Name -RepoUrl $RepoUrl -LocalPath $localPath -Purpose $Purpose -Language $Language -IncludeMode 'root' -Storage 'external-mirror' -Active:$Active -ProjectFiles @() -License $License -LicenseStatus $LicenseStatus -MirrorClass $MirrorClass -WorkflowRole $WorkflowRole -ModelAAllowedSourceAccess $true -ModelBAllowedSourceAccess $modelBAllowed -HandoffDoc $HandoffDoc -Notes $Notes
|
||||
}
|
||||
|
||||
function Get-HyperTwistMirrorEntries {
|
||||
param(
|
||||
[Parameter(Mandatory = $true)][string]$PermissiveMirrorsRoot,
|
||||
[Parameter(Mandatory = $true)][string]$RestrictiveMirrorsRoot,
|
||||
[Parameter(Mandatory = $true)][string]$CleanRoomSpecsRoot
|
||||
)
|
||||
|
||||
$entries = [System.Collections.Generic.List[object]]::new()
|
||||
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'hactarce-hyperspeedcube' -Name 'HactarCE - Hyperspeedcube' -RepoUrl 'https://github.com/HactarCE/Hyperspeedcube.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'HactarCE' -Repo 'Hyperspeedcube' -Purpose 'Runtime-side hypercubing foundation anchor and engine donor.' -Language 'Rust' -License 'MIT OR Apache-2.0' -LicenseStatus 'dual-permissive' -MirrorClass 'permissive' -WorkflowRole 'foundation-donor'))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'cubing-cubing-js' -Name 'cubing - cubing.js' -RepoUrl 'https://github.com/cubing/cubing.js.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'cubing' -Repo 'cubing.js' -Purpose 'Canonical classic-cubing semantics, rendering, scramble/search, and smartcube donor consumed through bounded MPL-aware dependency seams.' -Language 'TypeScript' -License 'MPL-2.0 OR GPL-3.0-or-later' -LicenseStatus 'dual-weak-copyleft-library-use-ok' -MirrorClass 'permissive' -WorkflowRole 'boundary-sensitive-donor' -Notes @('Preferred use is package dependency, adapter boundary, or bounded companion surface rather than a deep private fork.', 'If HyperTwist modifies cubing.js source files directly, those modifications must be published.', 'Preserve vendored-code and third-party notices documented by the upstream repo.')))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'kkoomen-qbr' -Name 'kkoomen - qbr' -RepoUrl 'https://github.com/kkoomen/qbr.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'kkoomen' -Repo 'qbr' -Purpose 'Primary classic-cube live recognition and calibration donor.' -Language 'Python' -License 'MIT' -LicenseStatus 'permissive' -MirrorClass 'permissive' -WorkflowRole 'foundation-donor'))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'vivaansinghvi07-rubix-cube-solver' -Name 'vivaansinghvi07 - rubix-cube-solver' -RepoUrl 'https://github.com/vivaansinghvi07/rubix-cube-solver.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'vivaansinghvi07' -Repo 'rubix-cube-solver' -Purpose 'Secondary browser/video reconstruction companion for the vision stack.' -Language 'JavaScript' -License 'MIT' -LicenseStatus 'permissive' -MirrorClass 'permissive' -WorkflowRole 'parallel-foundation-donor'))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'cahidenes-rubiks-cube-solver' -Name 'cahidenes - rubiks-cube-solver' -RepoUrl 'https://github.com/cahidenes/rubiks-cube-solver.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'cahidenes' -Repo 'rubiks-cube-solver' -Purpose 'Recognition heuristics and solver-bridge donor.' -Language 'Python' -License 'MIT' -LicenseStatus 'permissive' -MirrorClass 'permissive' -WorkflowRole 'strategic-donor'))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'tentone-rubix-solver' -Name 'tentone - rubix-solver' -RepoUrl 'https://github.com/tentone/rubix-solver.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'tentone' -Repo 'rubix-solver' -Purpose 'C++ and OpenCV perception-heuristics donor.' -Language 'C++' -License 'MIT' -LicenseStatus 'permissive' -MirrorClass 'permissive' -WorkflowRole 'strategic-donor'))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'yakupbilen-drl-rubiks-cube' -Name 'yakupbilen - drl-rubiks-cube' -RepoUrl 'https://github.com/yakupbilen/drl-rubiks-cube.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'yakupbilen' -Repo 'drl-rubiks-cube' -Purpose 'RL and search experimentation bench for the coaching stack.' -Language 'Python' -License 'MIT' -LicenseStatus 'permissive' -MirrorClass 'permissive' -WorkflowRole 'training-bench'))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'brianpeiris-riftsketch' -Name 'brianpeiris - RiftSketch' -RepoUrl 'https://github.com/brianpeiris/RiftSketch.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'brianpeiris' -Repo 'RiftSketch' -Purpose 'XR interaction reference and immersion donor.' -Language 'JavaScript' -License 'MIT' -LicenseStatus 'permissive' -MirrorClass 'permissive' -WorkflowRole 'reference-donor'))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'nuilab-code-vr' -Name 'NuiLab - code-vr' -RepoUrl 'https://github.com/NuiLab/code-vr.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'NuiLab' -Repo 'code-vr' -Purpose 'XR pedagogy and onboarding donor.' -Language 'Rust' -License 'MIT' -LicenseStatus 'permissive' -MirrorClass 'permissive' -WorkflowRole 'reference-donor'))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'hypercubers-hypercubing-xyz' -Name 'Hypercubers - hypercubing.xyz' -RepoUrl 'https://github.com/Hypercubers/hypercubing.xyz.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'Hypercubers' -Repo 'hypercubing.xyz' -Purpose 'Knowledge, curriculum, notation, and community donor for the hypercubing half of HyperTwist.' -Language 'Markdown/Python' -License 'MIT' -LicenseStatus 'permissive' -MirrorClass 'permissive' -WorkflowRole 'knowledge-foundation-donor' -Notes @('Use the GitHub source repo as canonical for active evaluation.', 'The local downloaded C:\\HyperTwist\\Hypercubing.xyz snapshot is intentionally excluded from active evaluation for now.')))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'roice3-magictile' -Name 'roice3 - MagicTile' -RepoUrl 'https://github.com/roice3/MagicTile.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'roice3' -Repo 'MagicTile' -Purpose 'Top-tier non-Euclidean geometry, topology, and generalized puzzle-construction donor for the hypercubing expansion lane.' -Language 'C#' -License 'MIT' -LicenseStatus 'permissive' -MirrorClass 'permissive' -WorkflowRole 'strategic-donor' -Notes @('Treat as a geometry/topology donor under the Hyperspeedcube anchor, not as the main product shell.', 'The underlying R3 tiling and topology layers are the primary salvage target, not the WinForms/OpenTK shell.')))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'cutelyaware-magiccube4d' -Name 'cutelyaware - magiccube4d' -RepoUrl 'https://github.com/cutelyaware/magiccube4d.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'cutelyaware' -Repo 'magiccube4d' -Purpose 'Legacy 4D hypercubing interaction, history, macro, and generic puzzle-description donor with explicit attribution and notice obligations.' -Language 'Java' -License 'Custom permissive attribution-request license' -LicenseStatus 'custom-permissive-attribution' -MirrorClass 'permissive' -WorkflowRole 'strategic-donor' -Notes @('Preserve upstream attribution in natural product-facing places such as About dialogs, source comments, or third-party notices, and include the project link http://superliminal.com/cube/cube.htm.', 'Primary salvage targets are 4D interaction grammar, history and macro semantics, generic puzzle boundaries, and proven legacy hypercubing workflow.', 'Track the provenance note in com\\donhatchsw\\util\\MyMath.java in project license records, but do not treat it as a standing blocker.')))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'roice3-magic120cell' -Name 'roice3 - Magic120Cell' -RepoUrl 'https://github.com/roice3/Magic120Cell.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'roice3' -Repo 'Magic120Cell' -Purpose 'Specialized 4D interaction, visibility, and puzzle-specific UX donor for the hypercubing expansion family.' -Language 'C++/C#' -License 'MIT' -LicenseStatus 'permissive' -MirrorClass 'permissive' -WorkflowRole 'strategic-donor' -Notes @('Treat as a specialized descendant in the MagicTile family, not as the main runtime or geometry foundation.', 'Primary salvage targets are 4D interaction grammar, visibility modes, twist-history UX, and advanced teaching-surface behavior.')))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'roice3-magiccube5d' -Name 'roice3 - MagicCube5D' -RepoUrl 'https://github.com/roice3/MagicCube5D.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'roice3' -Repo 'MagicCube5D' -Purpose 'Specialized 5D cube-family interaction, progress, macro, and teaching-surface donor.' -Language 'C++/C#' -License 'MIT' -LicenseStatus 'permissive' -MirrorClass 'permissive' -WorkflowRole 'strategic-donor' -Notes @('Treat as a specialized cube-family donor below Hyperspeedcube and MagicTile, not as a product-shell foundation.', 'Primary salvage targets are 5D interaction grammar, macros, solved-progress reporting, sticker/cubie finding, slice handling, and advanced teaching-surface behavior.')))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'poliva-cubedex' -Name 'poliva - cubedex' -RepoUrl 'https://github.com/poliva/cubedex.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'poliva' -Repo 'cubedex' -Purpose 'Smartcube-aware training UX and offline-first donor.' -Language 'TypeScript' -License 'MIT' -LicenseStatus 'permissive' -MirrorClass 'permissive' -WorkflowRole 'strategic-donor'))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'tao-yu-alg-trainer' -Name 'tao-yu - Alg-Trainer' -RepoUrl 'https://github.com/tao-yu/Alg-Trainer.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'tao-yu' -Repo 'Alg-Trainer' -Purpose 'Conceptual training-lane foundation candidate and heavy donor.' -Language 'JavaScript' -License 'MIT' -LicenseStatus 'permissive' -MirrorClass 'permissive' -WorkflowRole 'foundation-donor'))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'lykos-cube-trainer' -Name 'Lykos - cube_trainer' -RepoUrl 'https://github.com/Lykos/cube_trainer.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'Lykos' -Repo 'cube_trainer' -Purpose 'Persistent training-domain and coaching-backend donor.' -Language 'Ruby' -License 'MIT' -LicenseStatus 'permissive' -MirrorClass 'permissive' -WorkflowRole 'strategic-donor'))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'newyork-anthonyng-rubiks-cross-trainer' -Name 'newyork-anthonyng - rubiks-cross-trainer' -RepoUrl 'https://github.com/newyork-anthonyng/rubiks-cross-trainer.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'newyork-anthonyng' -Repo 'rubiks-cross-trainer' -Purpose 'Focused CFOP cross-drill donor.' -Language 'JavaScript' -License 'MIT' -LicenseStatus 'permissive' -MirrorClass 'permissive' -WorkflowRole 'focused-donor'))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'abunickabhi-5style-trainer' -Name 'abunickabhi - 5style-Trainer' -RepoUrl 'https://github.com/abunickabhi/5style-Trainer.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'abunickabhi' -Repo '5style-Trainer' -Purpose 'Focused advanced-training donor for 5-style and BLD practice.' -Language 'JavaScript' -License 'MIT' -LicenseStatus 'permissive' -MirrorClass 'permissive' -WorkflowRole 'focused-donor'))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'aarav2709-kubetimr' -Name 'Aarav2709 - KubeTimr' -RepoUrl 'https://github.com/Aarav2709/KubeTimr.git' -MirrorRoot $PermissiveMirrorsRoot -Owner 'Aarav2709' -Repo 'KubeTimr' -Purpose 'Focused timer, splits, stats, and local-practice donor.' -Language 'TypeScript' -License 'MIT' -LicenseStatus 'permissive' -MirrorClass 'permissive' -WorkflowRole 'focused-donor'))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'amontesl-codexr' -Name 'aMonteSl - CodeXR' -RepoUrl 'https://github.com/aMonteSl/CodeXR.git' -MirrorRoot $RestrictiveMirrorsRoot -Owner 'aMonteSl' -Repo 'CodeXR' -Purpose 'Off-domain XR reference under strong copyleft; keep only as restrictive reference material.' -Language 'TypeScript' -License 'GPL-3.0' -LicenseStatus 'strong-copyleft' -MirrorClass 'restrictive' -WorkflowRole 'reference-only' -Notes @('Model B must not read this mirror.')))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'avikaufman-rubix-cube-trainer' -Name 'AviKaufman - Rubix-cube-trainer' -RepoUrl 'https://github.com/AviKaufman/Rubix-cube-trainer.git' -MirrorRoot $RestrictiveMirrorsRoot -Owner 'AviKaufman' -Repo 'Rubix-cube-trainer' -Purpose 'Clean-room pedagogy benchmark for beginner-method lesson flow.' -Language 'TypeScript' -License 'All rights reserved' -LicenseStatus 'all-rights-reserved' -MirrorClass 'restrictive' -WorkflowRole 'clean-room-candidate' -HandoffDoc (Join-Path $CleanRoomSpecsRoot 'avi-kaufman-rubix-cube-trainer.model-a.md') -Notes @('Model B must not read this mirror.', 'Use only the scrubbed Model A dossier and acceptance tests for later implementation.')))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'ambisinister-blindsolve' -Name 'ambisinister - blindsolve' -RepoUrl 'https://github.com/ambisinister/blindsolve.git' -MirrorRoot $RestrictiveMirrorsRoot -Owner 'ambisinister' -Repo 'blindsolve' -Purpose 'Clean-room BLD memo benchmark for hide-reveal and letter-pair rehearsal flow.' -Language 'Python' -License 'No explicit license found' -LicenseStatus 'license-missing' -MirrorClass 'restrictive' -WorkflowRole 'clean-room-candidate' -HandoffDoc (Join-Path $CleanRoomSpecsRoot 'ambisinister-blindsolve.model-a.md') -Notes @('Model B must not read this mirror.', 'Use only the scrubbed Model A dossier and acceptance tests for later implementation.')))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'alinen-cube' -Name 'alinen - cube' -RepoUrl 'https://github.com/alinen/cube.git' -MirrorRoot $RestrictiveMirrorsRoot -Owner 'alinen' -Repo 'cube' -Purpose 'Clean-room planner benchmark for modular state, task, and step-planner behavior.' -Language 'C#' -License 'No explicit license found' -LicenseStatus 'license-missing' -MirrorClass 'restrictive' -WorkflowRole 'clean-room-candidate' -HandoffDoc (Join-Path $CleanRoomSpecsRoot 'alinen-cube.model-a.md') -Notes @('Model B must not read this mirror.', 'Use only the scrubbed Model A dossier and acceptance tests for later implementation.')))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'brownan-rubiks-cube-solver' -Name 'brownan - Rubiks-Cube-Solver' -RepoUrl 'https://github.com/brownan/Rubiks-Cube-Solver.git' -MirrorRoot $RestrictiveMirrorsRoot -Owner 'brownan' -Repo 'Rubiks-Cube-Solver' -Purpose 'Primary benchmark oracle and approved clean-room target for a future first-party optimal-solver lane.' -Language 'C' -License 'GPL-3.0' -LicenseStatus 'strong-copyleft' -MirrorClass 'restrictive' -WorkflowRole 'clean-room-candidate' -HandoffDoc (Join-Path $CleanRoomSpecsRoot 'brownan-rubiks-cube-solver.model-a.md') -Notes @('Retain this repo as a correctness and optimality oracle even if a first-party solver is later implemented.', 'Model B must not read this mirror.')))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'mathewkj2048-rubiks-cube-simulator' -Name 'MathewKJ2048 - Rubiks-cube-simulator' -RepoUrl 'https://github.com/MathewKJ2048/Rubiks-cube-simulator.git' -MirrorRoot $RestrictiveMirrorsRoot -Owner 'MathewKJ2048' -Repo 'Rubiks-cube-simulator' -Purpose 'Low-priority clean-room simulator benchmark for lightweight move grammar, history, and timed playback behavior.' -Language 'Java' -License 'GPL-3.0' -LicenseStatus 'strong-copyleft' -MirrorClass 'restrictive' -WorkflowRole 'clean-room-candidate' -HandoffDoc (Join-Path $CleanRoomSpecsRoot 'mathewkj2048-rubiks-cube-simulator.model-a.md') -Notes @('Model B must not read this mirror.', 'Use only the scrubbed Model A dossier and acceptance tests for later implementation.')))
|
||||
$entries.Add((New-ExternalMirrorEntry -Key 'vwcwong-cubesim' -Name 'vwcwong - CubeSim' -RepoUrl 'https://github.com/vwcwong/CubeSim.git' -MirrorRoot $RestrictiveMirrorsRoot -Owner 'vwcwong' -Repo 'CubeSim' -Purpose 'Clean-room state/history/simulator benchmark for renderer-independent cube-domain design.' -Language 'Python' -License 'GPL-3.0' -LicenseStatus 'strong-copyleft' -MirrorClass 'restrictive' -WorkflowRole 'clean-room-candidate' -HandoffDoc (Join-Path $CleanRoomSpecsRoot 'vwcwong-cubesim.model-a.md') -Notes @('Model B must not read this mirror.', 'Use only the scrubbed Model A dossier and acceptance tests for later implementation.')))
|
||||
|
||||
return $entries
|
||||
}
|
||||
|
||||
function Get-ProductConfig {
|
||||
param(
|
||||
[Parameter(Mandatory = $true)][ValidateSet('ScriptoriumAI', 'HyperTwist', 'VectorShell')][string]$Name,
|
||||
[Parameter(Mandatory = $true)][string]$WorkspaceBasePath
|
||||
)
|
||||
|
||||
$workspaceRoot = Join-Path $WorkspaceBasePath $Name
|
||||
$mirrorsRoot = Join-Path $workspaceRoot 'mirrors'
|
||||
$permissiveMirrorsRoot = Join-Path $mirrorsRoot 'permissive'
|
||||
$restrictiveMirrorsRoot = Join-Path $mirrorsRoot 'restrictive'
|
||||
$cleanRoomSpecsRoot = Join-Path $workspaceRoot 'clean-room-specs'
|
||||
$implementationWorkspacesRoot = Join-Path $workspaceRoot 'implementation-workspaces'
|
||||
$modelBWorkspacesRoot = Join-Path $implementationWorkspacesRoot 'model-b'
|
||||
$scratchWorkspacesRoot = Join-Path $implementationWorkspacesRoot 'scratch'
|
||||
$generatedRoot = Join-Path $workspaceRoot 'generated'
|
||||
$cacheRoot = Join-Path $workspaceRoot 'cache'
|
||||
$plannedAppRoot = Join-Path $workspaceRoot 'app'
|
||||
|
||||
switch ($Name) {
|
||||
'ScriptoriumAI' {
|
||||
return [ordered]@{
|
||||
Name = $Name
|
||||
RepoRoot = 'C:\ScriptoriumAI'
|
||||
DocsRoot = 'C:\ScriptoriumAI\docs'
|
||||
WorkspaceRoot = $workspaceRoot
|
||||
PlannedAppRoot = $plannedAppRoot
|
||||
MirrorsRoot = $mirrorsRoot
|
||||
PermissiveMirrorsRoot = $permissiveMirrorsRoot
|
||||
RestrictiveMirrorsRoot = $restrictiveMirrorsRoot
|
||||
CleanRoomSpecsRoot = $cleanRoomSpecsRoot
|
||||
ImplementationWorkspacesRoot = $implementationWorkspacesRoot
|
||||
ModelBWorkspacesRoot = $modelBWorkspacesRoot
|
||||
ScratchWorkspacesRoot = $scratchWorkspacesRoot
|
||||
GeneratedRoot = $generatedRoot
|
||||
CacheRoot = $cacheRoot
|
||||
RepositoryEntries = @(
|
||||
(New-RepositoryEntry -Key 'app' -Name 'ScriptoriumAI App' -RepoUrl '' -LocalPath 'C:\ScriptoriumAI' -Purpose 'First-party product repository.' -Language 'mixed' -IncludeMode 'project' -Storage 'app-repo' -ProjectFiles @(
|
||||
[ordered]@{ name = 'ScriptoriumAI'; path = 'C:\ScriptoriumAI\ScriptoriumAI.vcxproj'; kind = 'cpp' },
|
||||
[ordered]@{ name = 'scriptoriumai-ui'; path = 'C:\ScriptoriumAI\scriptoriumai-ui\scriptoriumai-ui.esproj'; kind = 'js' },
|
||||
[ordered]@{ name = 'ScriptoriumAI-Server'; path = 'C:\ScriptoriumAI\ScriptoriumAI-Server\ScriptoriumAI-Server.esproj'; kind = 'js' }
|
||||
) -License 'first-party' -LicenseStatus 'first-party' -MirrorClass 'app-repo' -WorkflowRole 'first-party' -ModelAAllowedSourceAccess $true -ModelBAllowedSourceAccess $true),
|
||||
(New-RepositoryEntry -Key 'gitnexus' -Name 'GitNexus' -RepoUrl 'https://github.com/abhigyanpatwari/GitNexus.git' -LocalPath 'C:\ScriptoriumAI\mirrors\GitNexus' -Purpose 'Pinned internal code-intelligence tooling retained as an in-repo submodule.' -Language 'TypeScript' -IncludeMode 'root' -Storage 'submodule' -License 'unknown' -LicenseStatus 'pending' -MirrorClass 'in-repo' -WorkflowRole 'pinned-dependency'),
|
||||
(New-RepositoryEntry -Key 'claude-skills' -Name 'claude-skills' -RepoUrl 'https://github.com/alirezarezvani/claude-skills.git' -LocalPath 'C:\ScriptoriumAI\mirrors\claude-skills' -Purpose 'Pinned skills corpus used by the skills-management flow.' -Language 'Markdown' -IncludeMode 'root' -Storage 'submodule' -License 'unknown' -LicenseStatus 'pending' -MirrorClass 'in-repo' -WorkflowRole 'pinned-dependency'),
|
||||
(New-RepositoryEntry -Key 'awesome-claude-skills' -Name 'awesome-claude-skills' -RepoUrl 'https://github.com/ComposioHQ/awesome-claude-skills.git' -LocalPath 'C:\ScriptoriumAI\mirrors\awesome-claude-skills' -Purpose 'Pinned scout source for skill ingestion.' -Language 'Markdown' -IncludeMode 'root' -Storage 'submodule' -License 'unknown' -LicenseStatus 'pending' -MirrorClass 'in-repo' -WorkflowRole 'pinned-dependency'),
|
||||
(New-RepositoryEntry -Key 'latexocr' -Name 'latexocr' -RepoUrl 'https://github.com/lukas-blecher/LaTeX-OCR.git' -LocalPath 'C:\ScriptoriumAI\mirrors\latexocr' -Purpose 'OCR runtime used by equation-to-LaTeX services.' -Language 'Python' -IncludeMode 'root' -Storage 'submodule' -License 'unknown' -LicenseStatus 'pending' -MirrorClass 'in-repo' -WorkflowRole 'pinned-dependency'),
|
||||
(New-RepositoryEntry -Key 'pdfdelta' -Name 'pdfdelta' -RepoUrl 'https://github.com/balajisivaraman/pdfdelta.git' -LocalPath 'C:\ScriptoriumAI\mirrors\pdfdelta' -Purpose 'PDF differencing assets and examples referenced by runboard flows.' -Language 'mixed' -IncludeMode 'root' -Storage 'submodule' -License 'unknown' -LicenseStatus 'pending' -MirrorClass 'in-repo' -WorkflowRole 'pinned-dependency'),
|
||||
(New-RepositoryEntry -Key 'pdfmd' -Name 'pdfmd' -RepoUrl 'https://github.com/reez/pdfmd.git' -LocalPath 'C:\ScriptoriumAI\mirrors\pdfmd' -Purpose 'PDF-to-Markdown tooling kept pinned for intake and tests.' -Language 'mixed' -IncludeMode 'root' -Storage 'submodule' -License 'unknown' -LicenseStatus 'pending' -MirrorClass 'in-repo' -WorkflowRole 'pinned-dependency'),
|
||||
(New-RepositoryEntry -Key 'code2video' -Name 'code2video' -RepoUrl 'https://github.com/itsjavi/code2video.git' -LocalPath 'C:\ScriptoriumAI\mirrors\code2video' -Purpose 'Code-to-video transform engine referenced by server services.' -Language 'mixed' -IncludeMode 'root' -Storage 'submodule' -License 'unknown' -LicenseStatus 'pending' -MirrorClass 'in-repo' -WorkflowRole 'pinned-dependency'),
|
||||
(New-RepositoryEntry -Key 'paper2video' -Name 'paper2video' -RepoUrl 'https://github.com/harish-03/paper2video.git' -LocalPath 'C:\ScriptoriumAI\mirrors\paper2video' -Purpose 'Paper-to-video transform engine referenced by server services.' -Language 'mixed' -IncludeMode 'root' -Storage 'submodule' -License 'unknown' -LicenseStatus 'pending' -MirrorClass 'in-repo' -WorkflowRole 'pinned-dependency'),
|
||||
(New-RepositoryEntry -Key 'liquid-glass-react' -Name 'liquid-glass-react' -RepoUrl 'https://github.com/rdev/liquid-glass-react.git' -LocalPath 'C:\ScriptoriumAI\mirrors\liquid-glass-react' -Purpose 'Pinned visual donor for the glass UI implementation.' -Language 'TypeScript' -IncludeMode 'root' -Storage 'submodule' -License 'unknown' -LicenseStatus 'pending' -MirrorClass 'in-repo' -WorkflowRole 'pinned-dependency')
|
||||
)
|
||||
}
|
||||
}
|
||||
'HyperTwist' {
|
||||
$entries = [System.Collections.Generic.List[object]]::new()
|
||||
$entries.Add((New-RepositoryEntry -Key 'app' -Name 'HyperTwist App' -RepoUrl '' -LocalPath 'C:\HyperTwist' -Purpose 'First-party product repository.' -Language 'mixed' -IncludeMode 'project' -Storage 'app-repo' -ProjectFiles @(
|
||||
[ordered]@{ name = 'HyperTwist'; path = 'C:\HyperTwist\HyperTwist.vcxproj'; kind = 'cpp' }
|
||||
) -License 'first-party' -LicenseStatus 'first-party' -MirrorClass 'app-repo' -WorkflowRole 'first-party' -ModelAAllowedSourceAccess $true -ModelBAllowedSourceAccess $true))
|
||||
|
||||
foreach ($entry in (Get-HyperTwistMirrorEntries -PermissiveMirrorsRoot $permissiveMirrorsRoot -RestrictiveMirrorsRoot $restrictiveMirrorsRoot -CleanRoomSpecsRoot $cleanRoomSpecsRoot)) {
|
||||
$entries.Add($entry)
|
||||
}
|
||||
|
||||
return [ordered]@{
|
||||
Name = $Name
|
||||
RepoRoot = 'C:\HyperTwist'
|
||||
DocsRoot = 'C:\HyperTwist\docs'
|
||||
WorkspaceRoot = $workspaceRoot
|
||||
PlannedAppRoot = $plannedAppRoot
|
||||
MirrorsRoot = $mirrorsRoot
|
||||
PermissiveMirrorsRoot = $permissiveMirrorsRoot
|
||||
RestrictiveMirrorsRoot = $restrictiveMirrorsRoot
|
||||
CleanRoomSpecsRoot = $cleanRoomSpecsRoot
|
||||
ImplementationWorkspacesRoot = $implementationWorkspacesRoot
|
||||
ModelBWorkspacesRoot = $modelBWorkspacesRoot
|
||||
ScratchWorkspacesRoot = $scratchWorkspacesRoot
|
||||
GeneratedRoot = $generatedRoot
|
||||
CacheRoot = $cacheRoot
|
||||
RepositoryEntries = @($entries)
|
||||
}
|
||||
}
|
||||
'VectorShell' {
|
||||
return [ordered]@{
|
||||
Name = $Name
|
||||
RepoRoot = 'C:\VectorShell'
|
||||
DocsRoot = 'C:\VectorShell\docs'
|
||||
WorkspaceRoot = $workspaceRoot
|
||||
PlannedAppRoot = $plannedAppRoot
|
||||
MirrorsRoot = $mirrorsRoot
|
||||
PermissiveMirrorsRoot = $permissiveMirrorsRoot
|
||||
RestrictiveMirrorsRoot = $restrictiveMirrorsRoot
|
||||
CleanRoomSpecsRoot = $cleanRoomSpecsRoot
|
||||
ImplementationWorkspacesRoot = $implementationWorkspacesRoot
|
||||
ModelBWorkspacesRoot = $modelBWorkspacesRoot
|
||||
ScratchWorkspacesRoot = $scratchWorkspacesRoot
|
||||
GeneratedRoot = $generatedRoot
|
||||
CacheRoot = $cacheRoot
|
||||
RepositoryEntries = @(
|
||||
(New-RepositoryEntry -Key 'app' -Name 'VectorShell App' -RepoUrl '' -LocalPath 'C:\VectorShell' -Purpose 'First-party product repository.' -Language 'mixed' -IncludeMode 'project' -Storage 'app-repo' -ProjectFiles @(
|
||||
[ordered]@{ name = 'VectorShell'; path = 'C:\VectorShell\VectorShell.vcxproj'; kind = 'cpp' }
|
||||
) -License 'first-party' -LicenseStatus 'first-party' -MirrorClass 'app-repo' -WorkflowRole 'first-party' -ModelAAllowedSourceAccess $true -ModelBAllowedSourceAccess $true)
|
||||
)
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
function New-ManifestObject {
|
||||
param([Parameter(Mandatory = $true)][hashtable]$Config)
|
||||
|
||||
return [ordered]@{
|
||||
schemaVersion = 2
|
||||
productName = $Config.Name
|
||||
generatedAtUtc = (Get-Date).ToUniversalTime().ToString('o')
|
||||
workspace = [ordered]@{
|
||||
workspaceRoot = $Config.WorkspaceRoot
|
||||
currentAppRoot = $Config.RepoRoot
|
||||
plannedAppRoot = $Config.PlannedAppRoot
|
||||
mirrorsRoot = $Config.MirrorsRoot
|
||||
permissiveMirrorsRoot = $Config.PermissiveMirrorsRoot
|
||||
restrictiveMirrorsRoot = $Config.RestrictiveMirrorsRoot
|
||||
cleanRoomSpecsRoot = $Config.CleanRoomSpecsRoot
|
||||
implementationWorkspacesRoot = $Config.ImplementationWorkspacesRoot
|
||||
modelBWorkspacesRoot = $Config.ModelBWorkspacesRoot
|
||||
scratchWorkspacesRoot = $Config.ScratchWorkspacesRoot
|
||||
generatedRoot = $Config.GeneratedRoot
|
||||
cacheRoot = $Config.CacheRoot
|
||||
}
|
||||
policy = [ordered]@{
|
||||
defaultIncludeMode = 'root'
|
||||
promoteToProjectWhenEditing = $true
|
||||
shippingSource = 'currentAppRoot'
|
||||
moveAppIntoWorkspaceDeferred = $true
|
||||
restrictiveMirrorsModelAOnly = $true
|
||||
modelBMayReadRestrictiveMirrors = $false
|
||||
benchmarkOracleDefaultUsage = 'correctness-reference-and-test-oracle'
|
||||
cleanRoomDefaultUsage = 'model-a-spec-then-isolated-model-b-implementation'
|
||||
notes = @(
|
||||
'The live application repository remains at currentAppRoot for now.',
|
||||
'plannedAppRoot exists as the future migration target once a deliberate move is approved.',
|
||||
'Use storage=submodule only for repos that must remain pinned inside the product repo.',
|
||||
'Use storage=external-mirror for large intake queues and promote to project mode only when actively editing.',
|
||||
'Restrictive mirrors are for Model A research custody only. Model B must consume scrubbed handoff artifacts instead of source.',
|
||||
'Benchmark oracles may remain restrictive. Their main value is correctness, regression, and quality comparison rather than code reuse.'
|
||||
)
|
||||
}
|
||||
repositories = $Config.RepositoryEntries
|
||||
}
|
||||
}
|
||||
|
||||
function Write-WorkspaceReadmes {
|
||||
param([Parameter(Mandatory = $true)][hashtable]$Config)
|
||||
|
||||
Write-Utf8File -Path (Join-Path $Config.WorkspaceRoot 'README.md') -Lines @(
|
||||
"# $($Config.Name) external workspace",
|
||||
'',
|
||||
"This workspace is the external mirror and handoff control plane for $($Config.Name).",
|
||||
'',
|
||||
"Current live repo: $($Config.RepoRoot)",
|
||||
"Planned future app folder: $($Config.PlannedAppRoot)",
|
||||
"Permissive mirrors root: $($Config.PermissiveMirrorsRoot)",
|
||||
"Restrictive mirrors root: $($Config.RestrictiveMirrorsRoot)",
|
||||
"Clean-room specs root: $($Config.CleanRoomSpecsRoot)",
|
||||
"Implementation workspaces root: $($Config.ImplementationWorkspacesRoot)",
|
||||
'',
|
||||
'Operating rules:',
|
||||
'- Keep first-party shipping code in the live app repo until an explicit migration is approved.',
|
||||
'- Place permissive donor repos under mirrors\permissive.',
|
||||
'- Place GPL, no-license, and all-rights-reserved repos under mirrors\restrictive.',
|
||||
'- Treat clean-room-specs as the safe handoff zone from Model A to Model B.',
|
||||
'- Treat implementation-workspaces\model-b as the isolated implementation surface that must not read restrictive mirrors.'
|
||||
)
|
||||
|
||||
Write-Utf8File -Path (Join-Path $Config.PlannedAppRoot 'README.md') -Lines @(
|
||||
"# $($Config.Name) app placeholder",
|
||||
'',
|
||||
"This folder is reserved for a future migration of the live repo into the external workspace layout.",
|
||||
'',
|
||||
"Current live repo path: $($Config.RepoRoot)",
|
||||
'',
|
||||
'Do not move the repository here implicitly. The migration should be a separate, deliberate step.'
|
||||
)
|
||||
|
||||
Write-Utf8File -Path (Join-Path $Config.MirrorsRoot 'README.md') -Lines @(
|
||||
"# $($Config.Name) mirrors",
|
||||
'',
|
||||
'This folder is split by exposure and licensing posture:',
|
||||
'- permissive: MIT, Apache, BSD, or otherwise acceptable direct donor mirrors',
|
||||
'- restrictive: GPL, no-license, all-rights-reserved, or otherwise source-restricted mirrors',
|
||||
'',
|
||||
'Mirror rules:',
|
||||
'- Mirror repos by owner\repo to avoid collisions.',
|
||||
'- Keep manifest metadata current; do not treat ad hoc clone folders as authoritative.',
|
||||
'- Restrictive mirrors are Model A only.'
|
||||
)
|
||||
|
||||
Write-Utf8File -Path (Join-Path $Config.PermissiveMirrorsRoot 'README.md') -Lines @(
|
||||
"# $($Config.Name) permissive mirrors",
|
||||
'',
|
||||
'Use this root for repos whose source may be read during normal donor evaluation and, when appropriate, direct integration work.',
|
||||
'',
|
||||
'Default policy:',
|
||||
'- includeMode = root',
|
||||
'- storage = external-mirror',
|
||||
'- Model A source access = allowed',
|
||||
'- Model B source access = allowed if the repo remains in the permissive donor lane'
|
||||
)
|
||||
|
||||
Write-Utf8File -Path (Join-Path $Config.RestrictiveMirrorsRoot 'README.md') -Lines @(
|
||||
"# $($Config.Name) restrictive mirrors",
|
||||
'',
|
||||
'Use this root for GPL, no-license, all-rights-reserved, and otherwise source-restricted mirrors.',
|
||||
'',
|
||||
'Critical policy:',
|
||||
'- Model A source access = allowed for research, benchmark-oracle work, and clean-room specification work',
|
||||
'- Model B source access = forbidden',
|
||||
'- Later implementation must consume only scrubbed handoff artifacts from clean-room-specs'
|
||||
)
|
||||
|
||||
Write-Utf8File -Path (Join-Path $Config.CleanRoomSpecsRoot 'README.md') -Lines @(
|
||||
"# $($Config.Name) clean-room specs",
|
||||
'',
|
||||
'This root is the safe handoff zone for scrubbed Model A outputs.',
|
||||
'',
|
||||
'Expected contents:',
|
||||
'- behavior specifications',
|
||||
'- architecture notes at a black-box level',
|
||||
'- acceptance tests',
|
||||
'- no-copy guardrails',
|
||||
'- benchmark-oracle usage notes when a restrictive repo is kept only as a correctness reference',
|
||||
'',
|
||||
'Recommended naming pattern:',
|
||||
'- <owner>-<repo>.model-a.md for repo-specific clean-room handoff files',
|
||||
'- <owner>-<repo>.oracle.md for restrictive oracle guidance files',
|
||||
'- benchmark-oracle-vs-clean-room.md for the general distinction guide',
|
||||
'- model-a-model-b-prompts.md for reusable role prompts'
|
||||
)
|
||||
|
||||
Write-Utf8File -Path (Join-Path $Config.ImplementationWorkspacesRoot 'README.md') -Lines @(
|
||||
"# $($Config.Name) implementation workspaces",
|
||||
'',
|
||||
'This root is for isolated build and implementation work that consumes only approved inputs.',
|
||||
'',
|
||||
'Expected subfolders:',
|
||||
'- model-b: isolated clean-room implementation workspace',
|
||||
'- scratch: safe local experimentation that does not read restrictive mirrors'
|
||||
)
|
||||
|
||||
Write-Utf8File -Path (Join-Path $Config.ModelBWorkspacesRoot 'README.md') -Lines @(
|
||||
"# $($Config.Name) model-b workspace",
|
||||
'',
|
||||
'This directory is reserved for isolated clean-room implementation work.',
|
||||
'',
|
||||
'Rules:',
|
||||
'- do not clone or mount restrictive mirrors here',
|
||||
'- consume only scrubbed specs, tests, and handoff notes from clean-room-specs',
|
||||
'- if a session has already read restrictive source, do not use that session here'
|
||||
)
|
||||
|
||||
Write-Utf8File -Path (Join-Path $Config.ScratchWorkspacesRoot 'README.md') -Lines @(
|
||||
"# $($Config.Name) scratch workspace",
|
||||
'',
|
||||
'Use this directory for safe local experiments, temporary validation harnesses, and non-authoritative test projects.',
|
||||
'',
|
||||
'Do not treat this folder as the long-term source of truth.'
|
||||
)
|
||||
|
||||
Write-Utf8File -Path (Join-Path $Config.GeneratedRoot 'README.md') -Lines @(
|
||||
"# $($Config.Name) generated artifacts",
|
||||
'',
|
||||
'This directory is generated from repos.manifest.json.',
|
||||
'',
|
||||
'Artifacts:',
|
||||
'- main.sln: first-party projects plus active pinned integrations',
|
||||
'- catalog.sln: lightweight catalog view of mirrors, specs, and pinned dependencies',
|
||||
'- active.slnf: current working-set filter'
|
||||
)
|
||||
|
||||
Write-Utf8File -Path (Join-Path $Config.CacheRoot 'README.md') -Lines @(
|
||||
"# $($Config.Name) cache",
|
||||
'',
|
||||
'Use this directory for clone cache, bare mirrors, temporary sync state, or generated lookup tables that should not live in the live app repo.'
|
||||
)
|
||||
}
|
||||
|
||||
function Write-WorkspaceGitignore {
|
||||
param([Parameter(Mandatory = $true)][hashtable]$Config)
|
||||
|
||||
Write-Utf8File -Path (Join-Path $Config.WorkspaceRoot '.gitignore') -Lines @(
|
||||
'.vs/',
|
||||
'mirrors/',
|
||||
'cache/',
|
||||
'logs/',
|
||||
'tmp/',
|
||||
'implementation-workspaces/model-b/*',
|
||||
'!implementation-workspaces/model-b/README.md',
|
||||
'implementation-workspaces/scratch/*',
|
||||
'!implementation-workspaces/scratch/README.md',
|
||||
'*.user',
|
||||
'*.suo'
|
||||
)
|
||||
}
|
||||
|
||||
function Write-ManifestFile {
|
||||
param(
|
||||
[Parameter(Mandatory = $true)][hashtable]$Config,
|
||||
[Parameter(Mandatory = $true)][bool]$RefreshManifest
|
||||
)
|
||||
|
||||
$manifestPath = Join-Path $Config.WorkspaceRoot 'repos.manifest.json'
|
||||
if ((-not (Test-Path -LiteralPath $manifestPath)) -or $RefreshManifest) {
|
||||
$manifest = New-ManifestObject -Config $Config
|
||||
$json = $manifest | ConvertTo-Json -Depth 10
|
||||
[System.IO.File]::WriteAllText($manifestPath, $json + [Environment]::NewLine, [System.Text.UTF8Encoding]::new($false))
|
||||
}
|
||||
}
|
||||
|
||||
function Get-Manifest {
|
||||
param([Parameter(Mandatory = $true)][hashtable]$Config)
|
||||
|
||||
$manifestPath = Join-Path $Config.WorkspaceRoot 'repos.manifest.json'
|
||||
return Get-Content -LiteralPath $manifestPath -Raw | ConvertFrom-Json
|
||||
}
|
||||
|
||||
function Get-ProjectEntriesFromManifest {
|
||||
param([Parameter(Mandatory = $true)]$Manifest)
|
||||
|
||||
$entries = [System.Collections.Generic.List[hashtable]]::new()
|
||||
foreach ($repository in $Manifest.repositories) {
|
||||
foreach ($projectFile in $repository.projectFiles) {
|
||||
$kind = if ($projectFile.kind) { [string]$projectFile.kind } else {
|
||||
if ($projectFile.path -like '*.vcxproj') { 'cpp' } else { 'js' }
|
||||
}
|
||||
|
||||
$entries.Add([ordered]@{
|
||||
Name = [string]$projectFile.name
|
||||
Path = [string]$projectFile.path
|
||||
Kind = $kind
|
||||
Guid = New-StableGuid "project::$($projectFile.path)"
|
||||
})
|
||||
}
|
||||
}
|
||||
|
||||
return $entries
|
||||
}
|
||||
|
||||
function Write-SolutionFile {
|
||||
param(
|
||||
[Parameter(Mandatory = $true)][string]$SolutionPath,
|
||||
[Parameter(Mandatory = $true)][hashtable[]]$ProjectEntries,
|
||||
[Parameter(Mandatory = $true)][hashtable[]]$FolderEntries
|
||||
)
|
||||
|
||||
$folderProjectTypeGuid = '{2150E333-8FDC-42A3-9474-1A3956D46DE8}'
|
||||
$jsProjectTypeGuid = '{54A90642-561A-4BB1-A94E-469ADEE60C69}'
|
||||
$cppProjectTypeGuid = '{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}'
|
||||
$solutionDir = Split-Path -Path $SolutionPath -Parent
|
||||
$lines = [System.Collections.Generic.List[string]]::new()
|
||||
|
||||
$lines.Add('')
|
||||
$lines.Add('Microsoft Visual Studio Solution File, Format Version 12.00')
|
||||
$lines.Add('# Visual Studio Version 17')
|
||||
$lines.Add('VisualStudioVersion = 17.14.36307.6')
|
||||
$lines.Add('MinimumVisualStudioVersion = 10.0.40219.1')
|
||||
|
||||
foreach ($project in $ProjectEntries) {
|
||||
$projectTypeGuid = if ($project.Kind -eq 'js') { $jsProjectTypeGuid } else { $cppProjectTypeGuid }
|
||||
$relativeProjectPath = New-RelativePath -BasePath $solutionDir -TargetPath $project.Path
|
||||
$lines.Add("Project(`"$projectTypeGuid`") = `"$($project.Name)`", `"$relativeProjectPath`", `"$($project.Guid)`"")
|
||||
$lines.Add('EndProject')
|
||||
}
|
||||
|
||||
foreach ($folder in $FolderEntries) {
|
||||
$folderFiles = @()
|
||||
if ($null -ne $folder.Files) {
|
||||
$folderFiles = @($folder.Files | Where-Object { -not [string]::IsNullOrWhiteSpace([string]$_) -and (Test-Path -LiteralPath $_) })
|
||||
}
|
||||
|
||||
$lines.Add("Project(`"$folderProjectTypeGuid`") = `"$($folder.Name)`", `"$($folder.Name)`", `"$($folder.Guid)`"")
|
||||
if ($folderFiles.Count -gt 0) {
|
||||
$lines.Add("`tProjectSection(SolutionItems) = preProject")
|
||||
foreach ($filePath in $folderFiles) {
|
||||
$relativeFilePath = New-RelativePath -BasePath $solutionDir -TargetPath $filePath
|
||||
$lines.Add("`t`t$relativeFilePath = $relativeFilePath")
|
||||
}
|
||||
$lines.Add("`tEndProjectSection")
|
||||
}
|
||||
$lines.Add('EndProject')
|
||||
}
|
||||
|
||||
$lines.Add('Global')
|
||||
$lines.Add("`tGlobalSection(SolutionConfigurationPlatforms) = preSolution")
|
||||
$lines.Add("`t`tDebug|x64 = Debug|x64")
|
||||
$lines.Add("`t`tRelease|x64 = Release|x64")
|
||||
$lines.Add("`tEndGlobalSection")
|
||||
$lines.Add("`tGlobalSection(ProjectConfigurationPlatforms) = postSolution")
|
||||
foreach ($project in $ProjectEntries) {
|
||||
if ($project.Kind -eq 'cpp') {
|
||||
$lines.Add("`t`t$($project.Guid).Debug|x64.ActiveCfg = Debug|x64")
|
||||
$lines.Add("`t`t$($project.Guid).Debug|x64.Build.0 = Debug|x64")
|
||||
$lines.Add("`t`t$($project.Guid).Release|x64.ActiveCfg = Release|x64")
|
||||
$lines.Add("`t`t$($project.Guid).Release|x64.Build.0 = Release|x64")
|
||||
} else {
|
||||
$lines.Add("`t`t$($project.Guid).Debug|x64.ActiveCfg = Debug|Any CPU")
|
||||
$lines.Add("`t`t$($project.Guid).Release|x64.ActiveCfg = Release|Any CPU")
|
||||
}
|
||||
}
|
||||
$lines.Add("`tEndGlobalSection")
|
||||
|
||||
$nestedFolders = @($FolderEntries | Where-Object { $null -ne $_.ParentGuid -and $_.ParentGuid -ne '' })
|
||||
if ($nestedFolders.Count -gt 0) {
|
||||
$lines.Add("`tGlobalSection(NestedProjects) = preSolution")
|
||||
foreach ($folder in $nestedFolders) {
|
||||
$lines.Add("`t`t$($folder.Guid) = $($folder.ParentGuid)")
|
||||
}
|
||||
$lines.Add("`tEndGlobalSection")
|
||||
}
|
||||
|
||||
$lines.Add("`tGlobalSection(SolutionProperties) = preSolution")
|
||||
$lines.Add("`t`tHideSolutionNode = FALSE")
|
||||
$lines.Add("`tEndGlobalSection")
|
||||
$lines.Add('EndGlobal')
|
||||
|
||||
[System.IO.File]::WriteAllLines($SolutionPath, $lines, [System.Text.UTF8Encoding]::new($false))
|
||||
}
|
||||
|
||||
function Write-WorkspaceArtifacts {
|
||||
param(
|
||||
[Parameter(Mandatory = $true)][hashtable]$Config,
|
||||
[Parameter(Mandatory = $true)]$Manifest
|
||||
)
|
||||
|
||||
$projectEntries = Get-ProjectEntriesFromManifest -Manifest $Manifest
|
||||
|
||||
$workspaceConfigFiles = @(
|
||||
(Join-Path $Config.WorkspaceRoot 'README.md'),
|
||||
(Join-Path $Config.WorkspaceRoot 'repos.manifest.json'),
|
||||
(Join-Path $Config.WorkspaceRoot '.gitignore'),
|
||||
(Join-Path $Config.PlannedAppRoot 'README.md'),
|
||||
(Join-Path $Config.MirrorsRoot 'README.md'),
|
||||
(Join-Path $Config.PermissiveMirrorsRoot 'README.md'),
|
||||
(Join-Path $Config.RestrictiveMirrorsRoot 'README.md'),
|
||||
(Join-Path $Config.CleanRoomSpecsRoot 'README.md'),
|
||||
(Join-Path $Config.ImplementationWorkspacesRoot 'README.md'),
|
||||
(Join-Path $Config.ModelBWorkspacesRoot 'README.md'),
|
||||
(Join-Path $Config.ScratchWorkspacesRoot 'README.md'),
|
||||
(Join-Path $Config.GeneratedRoot 'README.md'),
|
||||
(Join-Path $Config.CacheRoot 'README.md')
|
||||
)
|
||||
|
||||
$workspaceConfigFolder = [ordered]@{
|
||||
Name = 'Workspace Config'
|
||||
Guid = New-StableGuid "$($Config.Name)::workspace-config"
|
||||
ParentGuid = $null
|
||||
Files = $workspaceConfigFiles
|
||||
}
|
||||
|
||||
$mainFolders = [System.Collections.Generic.List[hashtable]]::new()
|
||||
$mainFolders.Add($workspaceConfigFolder)
|
||||
|
||||
$pinnedIntegrations = @($Manifest.repositories | Where-Object { $_.storage -eq 'submodule' -and $_.active })
|
||||
if ($pinnedIntegrations.Count -gt 0) {
|
||||
$pinnedRootGuid = New-StableGuid "$($Config.Name)::pinned-root"
|
||||
$mainFolders.Add([ordered]@{
|
||||
Name = 'Pinned Integrations'
|
||||
Guid = $pinnedRootGuid
|
||||
ParentGuid = $null
|
||||
Files = @()
|
||||
})
|
||||
|
||||
foreach ($repository in $pinnedIntegrations) {
|
||||
$mainFolders.Add([ordered]@{
|
||||
Name = [string]$repository.name
|
||||
Guid = New-StableGuid "$($Config.Name)::main::$($repository.key)"
|
||||
ParentGuid = $pinnedRootGuid
|
||||
Files = @()
|
||||
})
|
||||
}
|
||||
}
|
||||
|
||||
Write-SolutionFile -SolutionPath (Join-Path $Config.GeneratedRoot 'main.sln') -ProjectEntries $projectEntries -FolderEntries $mainFolders
|
||||
|
||||
$catalogFolders = [System.Collections.Generic.List[hashtable]]::new()
|
||||
$catalogFolders.Add($workspaceConfigFolder)
|
||||
|
||||
$submoduleRepos = @($Manifest.repositories | Where-Object { $_.storage -eq 'submodule' })
|
||||
$permissiveRepos = @($Manifest.repositories | Where-Object { $_.storage -eq 'external-mirror' -and $_.mirrorClass -eq 'permissive' })
|
||||
$restrictiveRepos = @($Manifest.repositories | Where-Object { $_.storage -eq 'external-mirror' -and $_.mirrorClass -eq 'restrictive' })
|
||||
$cleanRoomDocs = @($Manifest.repositories | Where-Object { -not [string]::IsNullOrWhiteSpace([string]$_.handoffDoc) } | ForEach-Object { [string]$_.handoffDoc } | Select-Object -Unique)
|
||||
|
||||
if ($submoduleRepos.Count -gt 0) {
|
||||
$submoduleRootGuid = New-StableGuid "$($Config.Name)::catalog::submodules"
|
||||
$catalogFolders.Add([ordered]@{
|
||||
Name = 'Pinned Submodules'
|
||||
Guid = $submoduleRootGuid
|
||||
ParentGuid = $null
|
||||
Files = @()
|
||||
})
|
||||
|
||||
foreach ($repository in $submoduleRepos) {
|
||||
$catalogFolders.Add([ordered]@{
|
||||
Name = [string]$repository.name
|
||||
Guid = New-StableGuid "$($Config.Name)::catalog::$($repository.key)"
|
||||
ParentGuid = $submoduleRootGuid
|
||||
Files = @()
|
||||
})
|
||||
}
|
||||
}
|
||||
|
||||
$permissiveRootGuid = New-StableGuid "$($Config.Name)::catalog::permissive"
|
||||
$catalogFolders.Add([ordered]@{
|
||||
Name = 'Permissive Mirrors'
|
||||
Guid = $permissiveRootGuid
|
||||
ParentGuid = $null
|
||||
Files = @((Join-Path $Config.PermissiveMirrorsRoot 'README.md'))
|
||||
})
|
||||
|
||||
foreach ($repository in $permissiveRepos) {
|
||||
$catalogFolders.Add([ordered]@{
|
||||
Name = [string]$repository.name
|
||||
Guid = New-StableGuid "$($Config.Name)::catalog::$($repository.key)"
|
||||
ParentGuid = $permissiveRootGuid
|
||||
Files = @()
|
||||
})
|
||||
}
|
||||
|
||||
$restrictiveRootGuid = New-StableGuid "$($Config.Name)::catalog::restrictive"
|
||||
$catalogFolders.Add([ordered]@{
|
||||
Name = 'Restrictive Mirrors'
|
||||
Guid = $restrictiveRootGuid
|
||||
ParentGuid = $null
|
||||
Files = @((Join-Path $Config.RestrictiveMirrorsRoot 'README.md'))
|
||||
})
|
||||
|
||||
foreach ($repository in $restrictiveRepos) {
|
||||
$catalogFolders.Add([ordered]@{
|
||||
Name = [string]$repository.name
|
||||
Guid = New-StableGuid "$($Config.Name)::catalog::$($repository.key)"
|
||||
ParentGuid = $restrictiveRootGuid
|
||||
Files = @()
|
||||
})
|
||||
}
|
||||
|
||||
if ($cleanRoomDocs.Count -gt 0) {
|
||||
$cleanRoomRootGuid = New-StableGuid "$($Config.Name)::catalog::clean-room"
|
||||
$catalogFolders.Add([ordered]@{
|
||||
Name = 'Clean-Room Specs'
|
||||
Guid = $cleanRoomRootGuid
|
||||
ParentGuid = $null
|
||||
Files = @((Join-Path $Config.CleanRoomSpecsRoot 'README.md')) + $cleanRoomDocs
|
||||
})
|
||||
}
|
||||
|
||||
Write-SolutionFile -SolutionPath (Join-Path $Config.GeneratedRoot 'catalog.sln') -ProjectEntries $projectEntries -FolderEntries $catalogFolders
|
||||
|
||||
$solutionFilterPath = Join-Path $Config.GeneratedRoot 'active.slnf'
|
||||
$relativeProjectPaths = @($projectEntries | ForEach-Object {
|
||||
New-RelativePath -BasePath $Config.GeneratedRoot -TargetPath $_.Path
|
||||
})
|
||||
|
||||
$solutionFilter = [ordered]@{
|
||||
solution = [ordered]@{
|
||||
path = 'main.sln'
|
||||
projects = $relativeProjectPaths
|
||||
}
|
||||
} | ConvertTo-Json -Depth 5
|
||||
|
||||
[System.IO.File]::WriteAllText($solutionFilterPath, $solutionFilter + [Environment]::NewLine, [System.Text.UTF8Encoding]::new($false))
|
||||
}
|
||||
|
||||
function Initialize-Workspace {
|
||||
param([Parameter(Mandatory = $true)][hashtable]$Config)
|
||||
|
||||
foreach ($path in @(
|
||||
$Config.WorkspaceRoot,
|
||||
$Config.PlannedAppRoot,
|
||||
$Config.MirrorsRoot,
|
||||
$Config.PermissiveMirrorsRoot,
|
||||
$Config.RestrictiveMirrorsRoot,
|
||||
$Config.CleanRoomSpecsRoot,
|
||||
$Config.ImplementationWorkspacesRoot,
|
||||
$Config.ModelBWorkspacesRoot,
|
||||
$Config.ScratchWorkspacesRoot,
|
||||
$Config.GeneratedRoot,
|
||||
$Config.CacheRoot
|
||||
)) {
|
||||
Ensure-Directory -Path $path
|
||||
}
|
||||
|
||||
Write-WorkspaceReadmes -Config $Config
|
||||
Write-WorkspaceGitignore -Config $Config
|
||||
Write-ManifestFile -Config $Config -RefreshManifest:$ForceManifestRefresh
|
||||
$manifest = Get-Manifest -Config $Config
|
||||
Write-WorkspaceArtifacts -Config $Config -Manifest $manifest
|
||||
}
|
||||
|
||||
$productNames = if ($Product -eq 'All') {
|
||||
@('ScriptoriumAI', 'HyperTwist', 'VectorShell')
|
||||
} else {
|
||||
@($Product)
|
||||
}
|
||||
|
||||
foreach ($productName in $productNames) {
|
||||
$config = Get-ProductConfig -Name $productName -WorkspaceBasePath $WorkspaceBase
|
||||
Initialize-Workspace -Config $config
|
||||
Write-Host "Initialized external workspace scaffold for $productName at $($config.WorkspaceRoot)" -ForegroundColor Green
|
||||
}
|
||||
Loading…
Add table
Reference in a new issue