scriptoriumadmin/hypertwist
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Align knowledge and reconstruction row source truth

Browse source
This commit is contained in:
axiomlogicnexus 2026-05-28 00:50:17 +02:00
parent 2a2aff6fdb
commit 83ada94dd2
4 changed files with 67 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

56
docs/HYPERTWIST_LIVE_KNOWLEDGE_AND_RECONSTRUCTION_ROWS_SOURCE_ALIGNMENT_2026-05-28.md Normal file
View file

@ -0,0 +1,56 @@
# HyperTwist Live Knowledge and Reconstruction Rows Source Alignment - 2026-05-28
## Status
This document closes the row-source truth gap for two already-landed live
permissive rows whose `v6.3` operational, `Phase G`, and source-audit layers
were still using donor-era extraction and merge language after the later
implementation, hierarchy, and provenance passes.
## Affected rows
- `Hypercubers/hypercubing.xyz`
- `vivaansinghvi07/rubix-cube-solver`
## Current judgment
- these rows are already landed for their current justified slices
- the stale layer was the row-source pack still framing them as donor
promotion, merge-path, or extraction candidates rather than closed owner
lanes
- no product code change is justified from this pass
- no live-lane hierarchy doctrine changed from this pass
## Required row-source posture
For these rows the source pack must now say:
- `Hypercubers/hypercubing.xyz` is already landed for the exact first-party
hypercubing knowledge, notation, progression, software-reference, and
leaderboard-contract lane
- `vivaansinghvi07/rubix-cube-solver` is already landed for the exact
first-party committed-face reconstruction, browser/webcam shell, and bounded
solve-explanation/recommendation lane
- future work starts from owned HyperTwist surfaces, the live feature and
roadmap canon, and the landed packet/provenance authority, not fresh donor
extraction framing or merger-thesis routing
## Source basis
- `C:\HyperTwist\docs\HT_REPO_INCORPORATION_AUDIT_2026-05-11.md`
- `C:\HyperTwist\docs\HYPERTWIST_HYPERCUBING_XYZ_REFERENCE_INCORPORATION_PROVENANCE_BOARD_2026-05-27.md`
- `C:\HyperTwist\docs\HYPERTWIST_CLASSIC_SOLVER_ORACLE_AND_IMPLEMENTATION_HIERARCHY_RECONCILIATION_2026-05-27.md`
- `C:\HyperTwist\docs\REPO_LICENSE_TRACKING.md`
- `C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\FEATURE_REGISTRY.md`
- landed `Phase 3R-B`, `Phase 6R-C`, `Phase 6R-P`, and `Phase 6R-Q` packet
authority
- `C:\HyperTwist\docs\repo_portfolio_unified_operational_v6_3.csv`
- `C:\HyperTwist\docs\repo_portfolio_unified_phase_g_v6_3.csv`
- `C:\HyperTwist\docs\repo_portfolio_unified_source_audit_v6_3.csv`
## Final call
These rows are not open donor-candidate rows anymore.
They are already integrated for their current justified live permissive slices,
and the row-source pack must now describe them that way.

6
docs/repo_portfolio_unified_operational_v6_3.csv
View file

File diff suppressed because one or more lines are too long

6
docs/repo_portfolio_unified_phase_g_v6_3.csv
View file

File diff suppressed because one or more lines are too long

10
docs/repo_portfolio_unified_source_audit_v6_3.csv
View file

@ -1,11 +1,11 @@
"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","v6_3_live_state_2026_05_11","v6_3_reset_lane_2026_05_11","v6_3_reset_next_step_2026_05_11"
"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","v6_3_live_state_2026_05_11","v6_3_reset_lane_2026_05_11","v6_3_reset_next_step_2026_05_11"
"HactarCE/Hyperspeedcube","https://github.com/HactarCE/Hyperspeedcube","HyperTwist","Locked Foundation","nD / hypercubing simulation substrate","P0","20","9203","2.0","160.0","193.0","high","This row is already live for its current justified slices. Preserve the landed hyper puzzle catalog, notation, replay-log serialization, replay verification, stats-shape, solve-record, and puzzle-DSL authoring boundaries, and widen only through owned HyperTwist work.","integrate","direct","Validate the current first-party owner boundaries for HactarCE/Hyperspeedcube and record any narrower owned widening targets that remain after the landed Phase 6R-A/K/L/M/N slice.","Landed hyper catalog, notation, replay-log, replay verification, stats-shape, solve-record, and puzzle-DSL owner boundaries as live first-party material.","Inspect current first-party owner boundaries, landed packet scope, retained adjacent hyper/runtime families, and unresolved owned widening targets only.","Which remaining hyper owner gaps, if any, are not already covered by the landed HyperTwist code and the bounded Phase 6R-A/K/L/M/N packets?","Preserve as the landed first-party hyper owner lane. Start any future widening from owned HyperTwist surfaces, FEATURE_REGISTRY, ROADMAP, REPO_LICENSE_TRACKING, and the landed Phase 6R-A/K/L/M/N packets; do not route work through donor-extraction framing.","Treat current first-party HyperTwist code as the owner. Keep MagicTile, Magic120Cell, MagicCube5D, and retained benchmark rows as adjacent families or references, not donor merge targets for the already landed slice.","Repurpose here means: ordinary owned enhancement of the landed hyper owner lane, not subsystem harvesting from an external candidate queue.","","","","","","","","","","Owned widening only","The row is already live inside HyperTwist. Further work should start from first-party owner surfaces, feature registry, roadmap, license tracking, and landed packet authority rather than donor-transfer or merger-thesis framing.","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.","Owner-boundary note + owned widening criteria + explicit no-donor-thesis posture.","1) Which landed hyper owner boundaries are already closed
2) Which narrower owned widening targets, if any, remain
3) Which adjacent retained rows stay reference-only or family-adjacent","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 an already-landed first-party hyper owner lane and route all future work through owned widening.","Already-landed hyper owner row for bounded puzzle catalog, notation, replay, stats, and DSL families; no donor thesis remains for the current slice.","Audit HactarCE/Hyperspeedcube only as an already-landed permissive owner lane for HyperTwist. Validate current owner boundaries and identify owned widening targets only; do not frame it as a donor-merge candidate.","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.","Already landed: start from first-party owner surfaces and landed packet authority, not donor-transfer framing.","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.","implemented_live_permissive","landed_permissive_preserve","Later Phase 6R-A/K/L/M/N preserve sequence closed. Preserve as the landed first-party hyper puzzle catalog, notation, replay-log serialization, replay verification, stats-shape, solve-record, and puzzle-DSL authoring lane; start future widening from ROADMAP.md, FEATURE_REGISTRY.md, REPO_LICENSE_TRACKING.md, and the repo-specific landed Phase 6R packets, not from the old candidate queue wording."
"kkoomen/qbr","https://github.com/kkoomen/qbr","HyperTwist","Locked Foundation","Live cube-recognition substrate","P0","21","9204","4.0","158.0","191.0","high","This row is already live for its current justified slices. Preserve the landed recognition calibration, ordered face-observation, and webcam-shell boundaries, and widen only through owned HyperTwist work while keeping deferred multilingual and broader solve-shell ownership explicit.","integrate","direct","Validate the current first-party owner boundaries for kkoomen/qbr and record any narrower owned widening targets that remain after the landed Phase 6R-B/O slice.","Landed recognition calibration, ordered face-observation, webcam shell, and adjacent deferred remainder boundaries as live first-party material.","Inspect current first-party recognition owner boundaries, landed packet scope, retained adjacent recognition rows, and unresolved owned widening targets only.","Which remaining recognition or webcam-shell gaps, if any, are not already covered by the landed HyperTwist code and the bounded Phase 6R-B/O packets?","Preserve as the landed first-party recognition calibration and webcam-shell owner lane. Start any future widening from owned HyperTwist surfaces, FEATURE_REGISTRY, ROADMAP, REPO_LICENSE_TRACKING, and the landed Phase 6R-B/O packets; do not route work through donor-extraction framing.","Treat current first-party HyperTwist code as the owner. Keep rubix-cube-solver, the retained recognition-comparison adjunct rows, and the multilingual guidance remainder as adjacent retained or deferred families, not donor merge targets for the already landed slice.","Repurpose here means: ordinary owned enhancement of the landed recognition and webcam-shell owner lane, not external donor harvesting.","","","","","","","","","","Owned widening only","The row is already live inside HyperTwist. Further work should start from first-party owner surfaces, feature registry, roadmap, license tracking, and landed packet authority rather than donor-transfer or merger-thesis framing.","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.","Owner-boundary note + owned widening criteria + explicit no-donor-thesis posture.","1) Which landed recognition and webcam-shell owner boundaries are already closed
2) Which narrower owned widening targets, if any, remain
3) Which adjacent retained or deferred rows stay outside the landed slice","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 an already-landed first-party recognition owner lane and route all future work through owned widening.","Already-landed recognition owner row for bounded calibration, ordered observation, and webcam-shell families; no donor thesis remains for the current slice.","Audit kkoomen/qbr only as an already-landed permissive owner lane for HyperTwist. Validate current recognition and webcam-shell owner boundaries and identify owned widening targets only; do not frame it as a donor-merge candidate.","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.","Already landed: start from first-party owner surfaces and landed packet authority, not donor-transfer framing.","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.","implemented_live_permissive","landed_permissive_preserve","Later Phase 6R-B/O preserve sequence closed for the currently justified slice. Preserve as the landed first-party recognition calibration, ordered face-observation, and webcam-shell lane; start future widening from ROADMAP.md, FEATURE_REGISTRY.md, REPO_LICENSE_TRACKING.md, and the repo-specific landed Phase 6R packets, while keeping multilingual/font redistribution and broader solve-shell ownership deferred."
"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
"vivaansinghvi07/rubix-cube-solver","https://github.com/vivaansinghvi07/rubix-cube-solver","HyperTwist","Implemented reconstruction owner","Implemented committed-face reconstruction lane","P0","22","9205","8.0","158.0","191.0","high","This row is already live for its current justified slices. Preserve the landed first-party committed-face reconstruction, browser/webcam shell, and bounded solve-explanation/recommendation lane, and widen only through owned HyperTwist work while keeping broader solver-backend ownership deferred.","integrate","direct","Validate current first-party committed-face reconstruction, browser/webcam shell, and bounded solve-explanation/recommendation owner boundaries and record only narrower owned widening targets, if any.","committed-face reconstruction, browser-shell metadata, stage-ladder guidance, recommendation state, replay or recognition handoff, and deferred solver boundary","Inspect current first-party reconstruction and browser-shell owner boundaries, landed packet scope, retained adjacent recognition or solver rows, and unresolved owned widening targets only.","Which remaining committed-face reconstruction, browser/webcam shell, or bounded solve-explanation/recommendation gaps, if any, are not already covered by the landed HyperTwist code and the bounded Phase 6R-C/P/Q packets?","Preserve as the landed first-party committed-face reconstruction, browser/webcam shell, and bounded solve-explanation/recommendation owner lane. Start any future widening from owned HyperTwist surfaces, FEATURE_REGISTRY, ROADMAP, REPO_LICENSE_TRACKING, and the landed Phase 6R-C/P/Q packets; do not route work through donor-extraction framing.","Treat current first-party HyperTwist recognition and training surfaces as the owner. Keep qbr as the adjacent calibration and ordered face-observation owner, and keep retained solver or oracle rows separate rather than donor merge targets for the already landed slice.","Repurpose here means: ordinary owned enhancement of the landed reconstruction, browser-shell, and bounded solve-guidance lane, not external donor harvesting.","","","","","","","","","","Owned widening only","The row is already live inside HyperTwist. Further work should start from first-party owner surfaces, feature registry, roadmap, license tracking, and landed packet authority rather than donor-transfer or merger-thesis framing.","Keep current tier unless source shows the landed owner slice was overstated or materially misattributed.","Downgrade only if the claimed first-party owner slice is materially unsupported by current code or landed packets.","Owner-boundary note + owned widening criteria + explicit landed permissive-preserve posture.","1) Confirmed visible capabilities
2) Hidden capabilities found only in source
3) Best salvageable modules/files/packages
4) Integration path into target project
@ -13,7 +13,7 @@
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.","implemented_live_permissive","landed_permissive_preserve","Later Phase 6R-C/P/Q preserve sequence closed for the currently justified slice. Preserve as the landed first-party committed-face reconstruction, browser/webcam shell, and bounded solve-explanation/recommendation lane; start future widening from ROADMAP.md, FEATURE_REGISTRY.md, REPO_LICENSE_TRACKING.md, and the repo-specific landed Phase 6R packets, while broad solver-backend ownership and bundled twistysim.min.js redistribution stay deferred."
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.","Already-landed first-party committed-face reconstruction, browser/webcam shell, and bounded solve-explanation/recommendation owner lane.","The row is already live for its current justified reconstruction and bounded solve-guidance slice. No donor thesis remains for the landed owner lane.","Audit vivaansinghvi07/rubix-cube-solver only as an already-landed permissive owner lane for HyperTwist. Validate current committed-face reconstruction, browser/webcam shell, and bounded solve-explanation/recommendation owner boundaries and identify owned widening targets only; do not frame it as a donor-merge candidate.","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","The repo is MIT and the justified HyperTwist slice is already implemented as a first-party owner lane. Future widening should stay on owned HyperTwist surfaces while preserving notices, attribution, and the current bundled-asset exclusions.","Already landed: start from first-party owner surfaces and landed Phase 6R-C/P/Q packet authority, not donor-transfer framing.","Preserve MIT notices and attribution where required, and keep bundled twistysim.min.js redistribution out of scope unless separately justified.","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.","implemented_live_permissive","landed_permissive_preserve","Later Phase 6R-C/P/Q preserve sequence closed for the currently justified slice. Preserve as the landed first-party committed-face reconstruction, browser/webcam shell, and bounded solve-explanation/recommendation lane; start future widening from ROADMAP.md, FEATURE_REGISTRY.md, REPO_LICENSE_TRACKING.md, and the repo-specific landed Phase 6R packets, while broad solver-backend ownership and bundled twistysim.min.js redistribution stay deferred."
"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","This row is already live for its current justified slices. Preserve the landed broad algorithm-training shell, set or subset corpus, timer or reveal or scramble or virtual-cube flow, and smartcube-capable drill posture, and widen only through owned HyperTwist work.","integrate","direct","Validate the current first-party owner boundaries for tao-yu/Alg-Trainer and record any narrower owned widening targets that remain after the landed training-foundation slice.","Landed broad algorithm-shell, set or subset corpus, timer or reveal or scramble or virtual-cube flow, and smartcube-capable drill boundaries as live first-party material.","Inspect current first-party training-foundation owner boundaries, retained adjacent coaching and timer families, and unresolved owned widening targets only.","Which remaining training-foundation gaps, if any, are not already covered by the landed HyperTwist code and the current Alg-Trainer preserve slice?","Preserve as the landed first-party algorithm-training foundation owner lane. Start any future widening from owned HyperTwist surfaces, the live training stack, FEATURE_REGISTRY, ROADMAP, and REPO_LICENSE_TRACKING; do not route work through donor-extraction framing.","Treat current first-party HyperTwist code as the owner. Keep cube_trainer as the adjacent persisted-coaching owner, KubeTimr as the timer substrate owner, and cross-planning or micro-drill lanes as narrower adjacent families rather than donor merge targets for the already landed slice.","Repurpose here means: ordinary owned enhancement of the landed algorithm-training foundation owner lane, not external donor harvesting.","","","","","","","","","","Owned widening only","The row is already live inside HyperTwist. Further work should start from first-party owner surfaces, feature registry, roadmap, license tracking, and landed packet authority rather than donor-transfer or merger-thesis framing.","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.","Owner-boundary note + owned widening criteria + explicit no-donor-thesis posture.","1) Which landed training-foundation owner boundaries are already closed
2) Which narrower owned widening targets, if any, remain
3) Which adjacent live or retained rows stay outside the landed slice","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 an already-landed first-party training-foundation owner lane and route all future work through owned widening.","Already-landed training-foundation owner row for broad algorithm-shell, case-corpus, drill-flow, and smartcube-capable drill families; no donor thesis remains for the current slice.","Audit tao-yu/Alg-Trainer only as an already-landed permissive owner lane for HyperTwist. Validate current training-foundation owner boundaries and identify owned widening targets only; do not frame it as a donor-merge candidate.","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.","Already landed: start from first-party owner surfaces and landed preserve authority, not donor-transfer framing.","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.","implemented_live_permissive","landed_permissive_preserve","Phase 1R closed. Preserve as a landed first-party permissive lane; keep notices and attribution visible and widen only through ordinary owned enhancement work."
@ -128,7 +128,7 @@
"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 research engine, but keep it below live product ownership. For this repo class, preserve sticker-state transition encoding, ADI state generation, batched neural search, and offline experiment loops while excluding camera UX, PyQt shell behavior, and near-term product runtime assumptions.","future candidate","architecture only","Capture the learned-heuristic search, anti-cancellation move-sequence, ADI state-generation, and offline experiment behaviors that justify keeping yakupbilen only as a research benchmark row.","54-sticker encoding, ADI state generation, anti-cancellation sequence logic, batched neural A* experimentation, and offline training-loop behavior as research benchmark material.","Inspect README/docs, cube-state model, move-transition tables, search loop, ADI generation, network architecture, training scripts, and experiment configuration. Look for reusable search research primitives rather than camera UX, PyQt shell flows, or live perception assumptions.","Inspect cube-state encoding; move-transition tables; ADI state generation; batched A* evaluation; value-network shape; offline training loop; and experiment boundaries. Explicitly exclude camera/perception shell claims from owner judgment.","Keep only as a research benchmark. Use it to shape first-party learned heuristic search, ADI state-generation, and offline solver experimentation if HyperTwist ever opens that lane; do not treat it as a live camera, calibration, recognition, or product-shell donor.","Keep behind the landed qbr and rubix-cube-solver recognition owners and behind the retained brownan/efrantar solver-oracle owners. Revisit only if HyperTwist intentionally opens a first-party ML search or offline experimentation lane.","Repurpose here means: mine cube-state transition encoding, ADI target-generation loops, batched heuristic-search experiments, and small value-network research rather than camera UX or product shell behavior.","","","","","","","","","","Reference only","Retain only as benchmark, oracle, acceptance-test, comparison, research, or clean-room-later 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.","Research benchmark note + bounded reusable primitives + explicit no-live-owner boundary.","1) What specific learned-search and ADI research value remains in yakupbilen/drl-rubiks-cube
2) What must stay research-only rather than product-donor
3) Experiment, oracle, or planning 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.","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 learned-search and offline experimentation benchmark for HyperTwist. Do not stop at README-level claims. Inspect cube-state encoding, move-transition tables, ADI generation, batched neural A* search, value-network shape, and experiment loops. Decide whether the repo remains a non-live research benchmark and identify only those primitives that would matter if a future first-party ML search lane is intentionally opened. Do not treat camera UX or PyQt shell behavior as owner evidence.","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","pattern_only_preferred","The repo is MIT and remains a research benchmark for learned heuristic search, ADI state generation, and offline experimentation rather than a near-term product donor.","Reference only: benchmark learned heuristic search and training experiments without near-term direct incorporation.","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.","not_live_reference_or_discard_candidate","phase0r_reference_benchmark_or_discard_eval","Packet 0R-E closed. Retain as an MIT research benchmark for learned heuristic search, ADI training loops, and offline experimentation rather than near-term product implementation."
"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
"Hypercubers/hypercubing.xyz","https://github.com/Hypercubers/hypercubing.xyz","HyperTwist","Implemented knowledge/reference owner","Implemented hypercubing knowledge/reference lane","P1","7483","9238","1.0","92.0","101.0","medium","This row is already live for its current justified slice. Preserve the landed first-party hypercubing knowledge, notation, progression, software-reference, and leaderboard-contract lane, and widen only through owned HyperTwist work.","integrate","direct","Validate current first-party hypercubing knowledge, notation, progression, software-reference, and leaderboard-contract owner boundaries and record only narrower owned widening targets, if any.","hypercubing knowledge surfaces, notation glossary, progression ladder, software matrix or directory, leaderboard or report contracts, and bundled reference targets","Inspect current first-party hypercubing knowledge/reference owner boundaries, landed packet scope, bundled reference targets, and unresolved owned widening targets only.","Which remaining hypercubing knowledge, notation, progression, software-reference, or leaderboard-contract gaps, if any, are not already covered by the landed HyperTwist code and the current bundled reference targets?","Preserve as the landed first-party hypercubing knowledge, notation, progression, software-reference, and leaderboard-contract owner lane. Start any future widening from owned HyperTwist surfaces, FEATURE_REGISTRY, the live-lane audit, REPO_LICENSE_TRACKING, and the landed Phase 3R-B packet; do not route work through donor-extraction framing.","Treat current first-party HyperTwist training knowledge and runtime surfaces as the owner. Keep Hyperspeedcube as the separate higher-dimensional runtime owner and cubing/cubing.js as the separate classic-cubing semantic owner rather than donor merge targets for the already landed slice.","Repurpose here means: ordinary owned enhancement of the landed hypercubing knowledge/reference lane, not external donor harvesting.","","","","","","","","","","Owned widening only","The row is already live inside HyperTwist. Further work should start from first-party owner surfaces, feature registry, live-lane audit, license tracking, and landed packet authority rather than donor-transfer or merger-thesis framing.","Keep current tier unless source shows the landed owner slice was overstated or materially misattributed.","Downgrade only if the claimed first-party knowledge/reference owner slice is materially unsupported by current code, packets, or bundled reference targets.","Owner-boundary note + owned widening criteria + explicit landed permissive-preserve posture.","1) Confirmed visible capabilities
2) Hidden capabilities found only in source
3) Best salvageable modules/files/packages
4) Integration path into target project
@ -136,7 +136,7 @@
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.","implemented_live_permissive","landed_permissive_preserve","Phase 3R-B closed. Preserve as the landed first-party hypercubing knowledge, notation, progression, software-reference, and leaderboard-contract lane; start future widening from the live-lane audit, then the 3R-B implementation packet, then REPO_LICENSE_TRACKING.md."
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.","Already-landed first-party hypercubing knowledge, notation, progression, software-reference, and leaderboard-contract owner lane.","The row is already live for its current justified knowledge/reference slice. No donor thesis remains for the landed owner lane.","Audit Hypercubers/hypercubing.xyz only as an already-landed permissive owner lane for HyperTwist. Validate current hypercubing knowledge, notation, progression, software-reference, and leaderboard-contract owner boundaries and identify owned widening targets only; do not frame it as a donor-merge candidate.","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 the justified HyperTwist slice is already implemented as a first-party knowledge/reference owner lane. Future widening should stay on owned HyperTwist surfaces while preserving notices, attribution, and provenance summaries.","Already landed: start from first-party owner surfaces, bundled reference targets, landed packet authority, and explicit provenance notes rather than donor-transfer framing.","Preserve MIT notices, attribution, and provenance summaries 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.","implemented_live_permissive","landed_permissive_preserve","Phase 3R-B closed. Preserve as the landed first-party hypercubing knowledge, notation, progression, software-reference, and leaderboard-contract lane; start future widening from the live-lane audit, then the 3R-B implementation packet, then REPO_LICENSE_TRACKING.md."
"Aarav2709/KubeTimr","https://github.com/Aarav2709/KubeTimr","HyperTwist","Donor Bench","Adjacency / future transfer","P2","7485","9240","2.0","88.0","97.0","medium","This row is already live for its current justified slices. Preserve the landed local timer lifecycle, inspection, split capture and editing, session stats, local persistence, and timer-scoped replay boundaries, and widen only through owned HyperTwist work.","repurpose","moderate modification","Validate the current first-party owner boundaries for Aarav2709/KubeTimr and record any narrower owned widening targets that remain after the landed timer-substrate slice.","Landed timer lifecycle, inspection, split capture, stats, local persistence, and timer-scoped replay boundaries as live first-party material.","Inspect current first-party timer owner boundaries, landed packet scope, retained timer oracle and reference rows, and unresolved owned widening targets only.","Which remaining timer-substrate gaps, if any, are not already covered by the landed HyperTwist code and the KubeTimr implementation packet?","Preserve as the landed first-party timer substrate owner lane. Start any future widening from owned HyperTwist surfaces, the timer implementation packet, FEATURE_REGISTRY, ROADMAP, and REPO_LICENSE_TRACKING; do not route work through donor-extraction framing.","Treat current first-party HyperTwist code as the owner. Keep cstimer as the retained restrictive oracle, cubing/qqTimer as legacy reference, and CubeDesk as adjacent live trainer-session and smart-device workflow composition rather than donor merge targets for the already landed slice.","Repurpose here means: ordinary owned enhancement of the landed timer substrate owner lane, not external donor harvesting.","","","","","","","","","","Owned widening only","The row is already live inside HyperTwist. Further work should start from first-party owner surfaces, feature registry, roadmap, license tracking, and landed packet authority rather than donor-transfer or merger-thesis framing.","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.","Owner-boundary note + owned widening criteria + explicit no-donor-thesis posture.","1) Which landed timer owner boundaries are already closed
2) Which narrower owned widening targets, if any, remain
3) Which adjacent retained oracle or reference rows stay outside the landed slice","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 an already-landed first-party timer owner lane and route all future work through owned widening.","Already-landed timer owner row for bounded lifecycle, inspection, split, persistence, stats, and timer-scoped replay families; no donor thesis remains for the current slice.","Audit Aarav2709/KubeTimr only as an already-landed permissive owner lane for HyperTwist. Validate current timer owner boundaries and identify owned widening targets only; do not frame it as a donor-merge candidate.","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.","Already landed: start from first-party owner surfaces and landed packet authority, not donor-transfer framing.","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.","implemented_live_permissive","landed_permissive_preserve","Phase 3R-A closed. Preserve as the landed first-party timer, inspection, splits, stats, persistence, and timer-scoped replay lane; start future widening from the live-lane audit, then the 3R-A implementation packet, then REPO_LICENSE_TRACKING.md."

1 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 v6_3_live_state_2026_05_11 v6_3_reset_lane_2026_05_11 v6_3_reset_next_step_2026_05_11
2 HactarCE/Hyperspeedcube https://github.com/HactarCE/Hyperspeedcube HyperTwist Locked Foundation nD / hypercubing simulation substrate P0 20 9203 2.0 160.0 193.0 high This row is already live for its current justified slices. Preserve the landed hyper puzzle catalog, notation, replay-log serialization, replay verification, stats-shape, solve-record, and puzzle-DSL authoring boundaries, and widen only through owned HyperTwist work. integrate direct Validate the current first-party owner boundaries for HactarCE/Hyperspeedcube and record any narrower owned widening targets that remain after the landed Phase 6R-A/K/L/M/N slice. Landed hyper catalog, notation, replay-log, replay verification, stats-shape, solve-record, and puzzle-DSL owner boundaries as live first-party material. Inspect current first-party owner boundaries, landed packet scope, retained adjacent hyper/runtime families, and unresolved owned widening targets only. Which remaining hyper owner gaps, if any, are not already covered by the landed HyperTwist code and the bounded Phase 6R-A/K/L/M/N packets? Preserve as the landed first-party hyper owner lane. Start any future widening from owned HyperTwist surfaces, FEATURE_REGISTRY, ROADMAP, REPO_LICENSE_TRACKING, and the landed Phase 6R-A/K/L/M/N packets; do not route work through donor-extraction framing. Treat current first-party HyperTwist code as the owner. Keep MagicTile, Magic120Cell, MagicCube5D, and retained benchmark rows as adjacent families or references, not donor merge targets for the already landed slice. Repurpose here means: ordinary owned enhancement of the landed hyper owner lane, not subsystem harvesting from an external candidate queue. Owned widening only The row is already live inside HyperTwist. Further work should start from first-party owner surfaces, feature registry, roadmap, license tracking, and landed packet authority rather than donor-transfer or merger-thesis framing. 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. Owner-boundary note + owned widening criteria + explicit no-donor-thesis posture. 1) Which landed hyper owner boundaries are already closed 2) Which narrower owned widening targets, if any, remain 3) Which adjacent retained rows stay reference-only or family-adjacent 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 an already-landed first-party hyper owner lane and route all future work through owned widening. Already-landed hyper owner row for bounded puzzle catalog, notation, replay, stats, and DSL families; no donor thesis remains for the current slice. Audit HactarCE/Hyperspeedcube only as an already-landed permissive owner lane for HyperTwist. Validate current owner boundaries and identify owned widening targets only; do not frame it as a donor-merge candidate. 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. Already landed: start from first-party owner surfaces and landed packet authority, not donor-transfer framing. 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. implemented_live_permissive landed_permissive_preserve Later Phase 6R-A/K/L/M/N preserve sequence closed. Preserve as the landed first-party hyper puzzle catalog, notation, replay-log serialization, replay verification, stats-shape, solve-record, and puzzle-DSL authoring lane; start future widening from ROADMAP.md, FEATURE_REGISTRY.md, REPO_LICENSE_TRACKING.md, and the repo-specific landed Phase 6R packets, not from the old candidate queue wording.
3 kkoomen/qbr https://github.com/kkoomen/qbr HyperTwist Locked Foundation Live cube-recognition substrate P0 21 9204 4.0 158.0 191.0 high This row is already live for its current justified slices. Preserve the landed recognition calibration, ordered face-observation, and webcam-shell boundaries, and widen only through owned HyperTwist work while keeping deferred multilingual and broader solve-shell ownership explicit. integrate direct Validate the current first-party owner boundaries for kkoomen/qbr and record any narrower owned widening targets that remain after the landed Phase 6R-B/O slice. Landed recognition calibration, ordered face-observation, webcam shell, and adjacent deferred remainder boundaries as live first-party material. Inspect current first-party recognition owner boundaries, landed packet scope, retained adjacent recognition rows, and unresolved owned widening targets only. Which remaining recognition or webcam-shell gaps, if any, are not already covered by the landed HyperTwist code and the bounded Phase 6R-B/O packets? Preserve as the landed first-party recognition calibration and webcam-shell owner lane. Start any future widening from owned HyperTwist surfaces, FEATURE_REGISTRY, ROADMAP, REPO_LICENSE_TRACKING, and the landed Phase 6R-B/O packets; do not route work through donor-extraction framing. Treat current first-party HyperTwist code as the owner. Keep rubix-cube-solver, the retained recognition-comparison adjunct rows, and the multilingual guidance remainder as adjacent retained or deferred families, not donor merge targets for the already landed slice. Repurpose here means: ordinary owned enhancement of the landed recognition and webcam-shell owner lane, not external donor harvesting. Owned widening only The row is already live inside HyperTwist. Further work should start from first-party owner surfaces, feature registry, roadmap, license tracking, and landed packet authority rather than donor-transfer or merger-thesis framing. 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. Owner-boundary note + owned widening criteria + explicit no-donor-thesis posture. 1) Which landed recognition and webcam-shell owner boundaries are already closed 2) Which narrower owned widening targets, if any, remain 3) Which adjacent retained or deferred rows stay outside the landed slice 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 an already-landed first-party recognition owner lane and route all future work through owned widening. Already-landed recognition owner row for bounded calibration, ordered observation, and webcam-shell families; no donor thesis remains for the current slice. Audit kkoomen/qbr only as an already-landed permissive owner lane for HyperTwist. Validate current recognition and webcam-shell owner boundaries and identify owned widening targets only; do not frame it as a donor-merge candidate. 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. Already landed: start from first-party owner surfaces and landed packet authority, not donor-transfer framing. 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. implemented_live_permissive landed_permissive_preserve Later Phase 6R-B/O preserve sequence closed for the currently justified slice. Preserve as the landed first-party recognition calibration, ordered face-observation, and webcam-shell lane; start future widening from ROADMAP.md, FEATURE_REGISTRY.md, REPO_LICENSE_TRACKING.md, and the repo-specific landed Phase 6R packets, while keeping multilingual/font redistribution and broader solve-shell ownership deferred.
4 vivaansinghvi07/rubix-cube-solver https://github.com/vivaansinghvi07/rubix-cube-solver HyperTwist Locked Parallel Foundation Implemented reconstruction owner Vision / reconstruction donor layer Implemented committed-face reconstruction lane 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. This row is already live for its current justified slices. Preserve the landed first-party committed-face reconstruction, browser/webcam shell, and bounded solve-explanation/recommendation lane, and widen only through owned HyperTwist work while keeping broader solver-backend ownership deferred. 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. Validate current first-party committed-face reconstruction, browser/webcam shell, and bounded solve-explanation/recommendation owner boundaries and record only narrower owned widening targets, if any. image pipeline, detection heuristics/models, cube-state reconstruction, calibration, temporal smoothing, replay model, solver handoff, AR/overlay hooks committed-face reconstruction, browser-shell metadata, stage-ladder guidance, recommendation state, replay or recognition handoff, and deferred solver boundary 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 current first-party reconstruction and browser-shell owner boundaries, landed packet scope, retained adjacent recognition or solver rows, and unresolved owned widening targets only. Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts. Which remaining committed-face reconstruction, browser/webcam shell, or bounded solve-explanation/recommendation gaps, if any, are not already covered by the landed HyperTwist code and the bounded Phase 6R-C/P/Q packets? 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. Preserve as the landed first-party committed-face reconstruction, browser/webcam shell, and bounded solve-explanation/recommendation owner lane. Start any future widening from owned HyperTwist surfaces, FEATURE_REGISTRY, ROADMAP, REPO_LICENSE_TRACKING, and the landed Phase 6R-C/P/Q packets; do not route work through donor-extraction framing. 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. Treat current first-party HyperTwist recognition and training surfaces as the owner. Keep qbr as the adjacent calibration and ordered face-observation owner, and keep retained solver or oracle rows separate rather than donor merge targets for the already landed slice. Repurpose here means: turn it into a perception microservice, cube-state API, replay generator, or AR overlay donor for HyperTwist. Repurpose here means: ordinary owned enhancement of the landed reconstruction, browser-shell, and bounded solve-guidance lane, not external donor harvesting. 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 Owned widening only VectorShell can borrow spatial/rendering and perception primitives; ScriptoriumAI can borrow tutorial/educational visualization patterns rather than the full engine. The row is already live inside HyperTwist. Further work should start from first-party owner surfaces, feature registry, roadmap, license tracking, and landed packet authority rather than donor-transfer or merger-thesis framing. Keep current tier unless source audit reveals architectural shallowness, hard-coded assumptions, missing extension points, or brittle internals. Keep current tier unless source shows the landed owner slice was overstated or materially misattributed. 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. Downgrade only if the claimed first-party owner slice is materially unsupported by current code or landed packets. Architecture note + salvage map + integration recipe + reclassification verdict Owner-boundary note + owned widening criteria + explicit landed permissive-preserve posture. 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. Already-landed first-party committed-face reconstruction, browser/webcam shell, and bounded solve-explanation/recommendation owner lane. Part of the irreducible core stack for HyperTwist; kept as the parallel foundation and strongest reconstruction companion to qbr. The row is already live for its current justified reconstruction and bounded solve-guidance slice. No donor thesis remains for the landed owner lane. 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. Audit vivaansinghvi07/rubix-cube-solver only as an already-landed permissive owner lane for HyperTwist. Validate current committed-face reconstruction, browser/webcam shell, and bounded solve-explanation/recommendation owner boundaries and identify owned widening targets only; do not frame it as a donor-merge candidate. 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. The repo is MIT and the justified HyperTwist slice is already implemented as a first-party owner lane. Future widening should stay on owned HyperTwist surfaces while preserving notices, attribution, and the current bundled-asset exclusions. Direct embed, vendored module, package dependency, or tightly integrated adapter as the architecture requires. Already landed: start from first-party owner surfaces and landed Phase 6R-C/P/Q packet authority, not donor-transfer framing. Typically preserve notices, attribution, and license text where required; no special copyleft-driven disclosure posture is normally needed. Preserve MIT notices and attribution where required, and keep bundled twistysim.min.js redistribution out of scope unless separately justified. 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. implemented_live_permissive landed_permissive_preserve Later Phase 6R-C/P/Q preserve sequence closed for the currently justified slice. Preserve as the landed first-party committed-face reconstruction, browser/webcam shell, and bounded solve-explanation/recommendation lane; start future widening from ROADMAP.md, FEATURE_REGISTRY.md, REPO_LICENSE_TRACKING.md, and the repo-specific landed Phase 6R packets, while broad solver-backend ownership and bundled twistysim.min.js redistribution stay deferred.
5 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 This row is already live for its current justified slices. Preserve the landed broad algorithm-training shell, set or subset corpus, timer or reveal or scramble or virtual-cube flow, and smartcube-capable drill posture, and widen only through owned HyperTwist work. integrate direct Validate the current first-party owner boundaries for tao-yu/Alg-Trainer and record any narrower owned widening targets that remain after the landed training-foundation slice. Landed broad algorithm-shell, set or subset corpus, timer or reveal or scramble or virtual-cube flow, and smartcube-capable drill boundaries as live first-party material. Inspect current first-party training-foundation owner boundaries, retained adjacent coaching and timer families, and unresolved owned widening targets only. Which remaining training-foundation gaps, if any, are not already covered by the landed HyperTwist code and the current Alg-Trainer preserve slice? Preserve as the landed first-party algorithm-training foundation owner lane. Start any future widening from owned HyperTwist surfaces, the live training stack, FEATURE_REGISTRY, ROADMAP, and REPO_LICENSE_TRACKING; do not route work through donor-extraction framing. Treat current first-party HyperTwist code as the owner. Keep cube_trainer as the adjacent persisted-coaching owner, KubeTimr as the timer substrate owner, and cross-planning or micro-drill lanes as narrower adjacent families rather than donor merge targets for the already landed slice. Repurpose here means: ordinary owned enhancement of the landed algorithm-training foundation owner lane, not external donor harvesting. Owned widening only The row is already live inside HyperTwist. Further work should start from first-party owner surfaces, feature registry, roadmap, license tracking, and landed packet authority rather than donor-transfer or merger-thesis framing. 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. Owner-boundary note + owned widening criteria + explicit no-donor-thesis posture. 1) Which landed training-foundation owner boundaries are already closed 2) Which narrower owned widening targets, if any, remain 3) Which adjacent live or retained rows stay outside the landed slice 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 an already-landed first-party training-foundation owner lane and route all future work through owned widening. Already-landed training-foundation owner row for broad algorithm-shell, case-corpus, drill-flow, and smartcube-capable drill families; no donor thesis remains for the current slice. Audit tao-yu/Alg-Trainer only as an already-landed permissive owner lane for HyperTwist. Validate current training-foundation owner boundaries and identify owned widening targets only; do not frame it as a donor-merge candidate. 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. Already landed: start from first-party owner surfaces and landed preserve authority, not donor-transfer framing. 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. implemented_live_permissive landed_permissive_preserve Phase 1R closed. Preserve as a landed first-party permissive lane; keep notices and attribution visible and widen only through ordinary owned enhancement work.
6 cubing/cubing.js https://github.com/cubing/cubing.js HyperTwist Locked Strategic Donor Implemented classic-cubing semantic boundary lane P1 24 9207 7.0 152.0 185.0 high This row is already live for its current justified slice. Preserve the landed classic-cubing semantic/runtime adapter lane and the practical MPL and notice boundary grounding beneath it, and widen only through owned HyperTwist work. integrate direct Validate the current first-party owner boundaries for cubing/cubing.js and record any narrower owned widening targets that remain after the landed classic-cubing semantic/runtime and MPL-boundary slice. Landed classic-cubing semantics, runtime adapter, viewer bridge, device/search boundary, Melinda bridge, and practical MPL compliance-boundary notes as live first-party material. Inspect current first-party classic-cubing semantic/runtime and MPL-boundary owner boundaries, retained adjacent parser and replay families, and unresolved owned widening targets only. Which remaining classic-cubing semantic/runtime adapter or MPL-boundary gaps, if any, are not already covered by the landed HyperTwist code and the current cubing.js preserve slice? Preserve as the landed first-party classic-cubing semantic/runtime and MPL-boundary owner lane. Start any future widening from owned HyperTwist surfaces, FEATURE_REGISTRY, ROADMAP, REPO_LICENSE_TRACKING, and the landed Phase 4R-A packet; do not route work through donor-extraction framing. Treat current first-party HyperTwist code as the owner. Keep cubing/twisty.js as the separate replay-shell lane and cubing/alg.js as the separate parser/AST lane rather than donor merge targets for the already landed slice. Repurpose here means: ordinary owned enhancement of the landed classic-cubing semantic/runtime and MPL-boundary lane, not external donor harvesting. Owned widening only The row is already live inside HyperTwist for its bounded boundary-sensitive slice. Further work should start from first-party owner surfaces, feature registry, roadmap, license tracking, and landed packet authority rather than donor-transfer or merger-thesis framing. 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. Owner-boundary note + owned widening criteria + explicit landed boundary-sensitive preserve posture. 1) Which landed classic-cubing semantic/runtime boundary owner slices are already closed 2) Which narrower owned widening targets, if any, remain 3) Which adjacent live parser or replay rows stay outside the landed slice 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 an already-landed first-party classic-cubing semantic/runtime and MPL-boundary owner lane and route all future work through owned widening under the practical MPL path. Already-landed classic-cubing semantic/runtime adapter and MPL-boundary grounding row; no donor thesis remains for the current slice. Audit cubing/cubing.js only as an already-landed boundary-sensitive owner lane for HyperTwist. Validate current classic-cubing semantic/runtime and MPL-boundary owner boundaries and identify owned widening targets only; do not frame it as a donor-merge candidate. 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, and the justified HyperTwist slice is already implemented through the practical MPL-side route. Keep future widening on first-party or package/dependency surfaces, preserve notice retention, and keep modified-file publication duty explicit if upstream-covered files are changed. Already landed boundary-sensitive: start from first-party outputs, landed packet authority, and the practical MPL notice path; do not reopen silent private-fork posture by default. Preserve MPL notices, attribution, and any modified-file publication duty where applicable, and keep the practical MPL path explicit in distribution notes. Usually unnecessary unless you later replace a narrow adapter or dependency seam to avoid upstream-covered file modification duties. high implemented-mpl-boundary-review yes v6.3_final_source_of_truth Assigned to HT_cube_semantics during cluster normalization on 2026-04-25. implemented_live_boundary_sensitive landed_boundary_sensitive_preserve Phase 4R-A is closed. Preserve as a landed boundary-sensitive first-party lane; keep the practical MPL path and notice duties explicit and widen only through ordinary owned enhancement work.
7 cubing/alg.js https://github.com/cubing/alg.js HyperTwist Donor Bench Implemented algorithm-language clean-room lane P2 25 9208 0.0 95.0 95.0 medium This row is already live for its current justified slice. Preserve the landed parser, owned AST, traversal, validation, keyboard-mapping, and share/interchange lane under the existing clean-room boundary, and widen only through owned HyperTwist work above the restrictive outputs. integrate architecture only Validate the current first-party owner boundaries for cubing/alg.js and record any narrower owned widening targets that remain after the landed algorithm-language clean-room slice. Landed parser, owned AST, traversal, validation, keyboard-mapping, and share/interchange boundaries as live first-party material through the clean-room route. Inspect current first-party algorithm-language clean-room owner boundaries, retained adjacent semantic and replay families, and unresolved owned widening targets only. Which remaining algorithm-language, parser, AST, traversal, validation, keyboard-mapping, or share/interchange gaps, if any, are not already covered by the landed HyperTwist code and the current clean-room preserve slice? Preserve as the landed first-party algorithm-language clean-room owner lane. Start any future widening from owned HyperTwist surfaces, FEATURE_REGISTRY, ROADMAP, REPO_LICENSE_TRACKING, and the landed clean-room outputs; do not route work through fresh donor-extraction framing. Treat current first-party HyperTwistAlgorithm/* code as the live owner above the restrictive outputs. Keep cubing/cubing.js as the adjacent classic-semantic owner and cubing/twisty.js as the adjacent replay-shell owner rather than donor merge targets for the already landed clean-room slice. Repurpose here means: ordinary owned enhancement above the landed algorithm-language clean-room outputs, not renewed restrictive-source harvesting. Owned widening only The row is already live inside HyperTwist through first-party clean-room outputs. Further work should start from those owner surfaces, feature registry, roadmap, license tracking, and landed clean-room authority rather than renewed restrictive-source extraction. 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. Owner-boundary note + owned widening criteria + explicit landed clean-room-preserve posture. 1) Which landed algorithm-language clean-room owner boundaries are already closed 2) Which narrower owned widening targets, if any, remain 3) Which adjacent live classic-cubing rows stay outside the landed slice Use v6 unified board + P0 tier packet + project design language + relevant family references. Keep in canon as an already-landed first-party algorithm-language clean-room owner lane and route all future work through owned widening above the restrictive outputs. Already-landed parser, AST, traversal, validation, keyboard-mapping, and share/interchange row through the clean-room route; no open donor thesis remains for the current slice. Audit cubing/alg.js only as an already-landed restrictive clean-room owner lane for HyperTwist. Validate current algorithm-language owner boundaries and identify owned widening targets only; do not frame it as a fresh donor-merge candidate. 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 upstream repo is GPL-3.0-or-later, but the justified HyperTwist slice is already implemented through a landed clean-room Model A / Model B route. Keep all future widening on first-party or scrubbed-authority surfaces, not direct source reuse. Already landed clean-room: start from first-party outputs and scrubbed preserve authority; do not reopen direct restrictive-source access by default. Direct incorporation would still require GPL-compatible distribution/compliance and is not the HyperTwist path. Already satisfied by the landed clean-room route; reopen only if a narrower first-party widening target truly requires a fresh scrubbed spec. high gpl-clean-room-donor yes v6.3_final_source_of_truth Assigned to HT_cube_semantics during cluster normalization on 2026-04-25. implemented_live_clean_room_verified landed_clean_room_preserve Phase 0R-D and later clean-room preserves are closed. Preserve as a landed restrictive clean-room precedent; keep the Model A / Model B chain explicit and widen only from first-party outputs or scrubbed specs.
8 cubing/twisty.js https://github.com/cubing/twisty.js HyperTwist Donor Bench Implemented replay shell clean-room lane P2 27 9210 0.0 95.0 95.0 medium This row is already live for its current justified slice. Preserve the landed replay-player shell, cursor or timeline transport, control-bar, visualization-selection, and fallback presentation lane under the existing clean-room boundary, and widen only through owned HyperTwist work above the restrictive outputs. integrate architecture only Validate the current first-party owner boundaries for cubing/twisty.js and record any narrower owned widening targets that remain after the landed replay shell clean-room slice. Landed replay-player shell, timeline transport, control-bar, visualization-selection, and fallback presentation boundaries as live first-party material through the clean-room route. Inspect current first-party replay shell clean-room owner boundaries, retained adjacent semantic and browser-support families, and unresolved owned widening targets only. Which remaining replay-player shell, timeline transport, control-bar, or fallback presentation gaps, if any, are not already covered by the landed HyperTwist code and the current clean-room preserve slice? Preserve as the landed first-party replay shell clean-room owner lane. Start any future widening from owned HyperTwist surfaces, FEATURE_REGISTRY, ROADMAP, REPO_LICENSE_TRACKING, and the landed clean-room outputs; do not route work through fresh donor-extraction framing. Treat current first-party HyperTwistSimulation code as the live owner above the restrictive outputs. Keep cubing/cubing.js as the adjacent classic-semantic owner, cubing/alg.js as the adjacent algorithm-language owner, and browser support lanes as adjacent support families rather than donor merge targets for the already landed clean-room slice. Repurpose here means: ordinary owned enhancement above the landed replay shell clean-room outputs, not renewed restrictive-source harvesting. Owned widening only The row is already live inside HyperTwist through first-party clean-room outputs. Further work should start from those owner surfaces, feature registry, roadmap, license tracking, and landed clean-room authority rather than renewed restrictive-source extraction. 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. Owner-boundary note + owned widening criteria + explicit landed clean-room-preserve posture. 1) Which landed replay-shell clean-room owner boundaries are already closed 2) Which narrower owned widening targets, if any, remain 3) Which adjacent live classic-cubing rows stay outside the landed slice Use v6 unified board + P0 tier packet + project design language + relevant family references. Keep in canon as an already-landed first-party replay shell clean-room owner lane and route all future work through owned widening above the restrictive outputs. Already-landed replay-player shell, cursor or timeline transport, control-bar, and fallback presentation row through the clean-room route; no open donor thesis remains for the current slice. Audit cubing/twisty.js only as an already-landed restrictive clean-room owner lane for HyperTwist. Validate current replay-shell owner boundaries and identify owned widening targets only; do not frame it as a fresh donor-merge candidate. 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 upstream repo is GPL-3.0-or-later, but the justified HyperTwist slice is already implemented through a landed clean-room Model A / Model B route. Keep all future widening on first-party or scrubbed-authority surfaces, not direct source reuse. Already landed clean-room: start from first-party outputs and scrubbed preserve authority; do not reopen direct restrictive-source access by default. Direct incorporation would still require GPL-compatible distribution/compliance and is not the HyperTwist path. Already satisfied by the landed clean-room route; reopen only if a narrower first-party widening target truly requires a fresh scrubbed spec. high gpl-clean-room-donor yes v6.3_final_source_of_truth Assigned to HT_cube_semantics during cluster normalization on 2026-04-25. implemented_live_clean_room_verified landed_clean_room_preserve Phase 0R-D and later clean-room preserves are closed. Preserve as a landed restrictive clean-room precedent; keep the Model A / Model B chain explicit and widen only from first-party outputs or scrubbed specs.
9 cahidenes/rubiks-cube-solver https://github.com/cahidenes/rubiks-cube-solver HyperTwist Locked Strategic Donor Retained face-placement and cube-string comparison adjunct P1 55 9211 4.0 148.0 174.0 high This row is already closed for its current justified retained slice. Preserve the retained face-placement, cube-string assembly, and optional two-opposite-corner comparison adjunct beneath the landed qbr, rubix-cube-solver, and first-party correction-stack owners, and reopen only if a narrower gap is later proven. integrate direct Confirm that cahidenes/rubiks-cube-solver remains a closed retained face-placement, cube-string assembly, and optional two-opposite-corner comparison adjunct beneath the landed qbr, rubix-cube-solver, and first-party correction-stack owners, and record only narrower reopen criteria, if any. image pipeline, detection heuristics/models, cube-state reconstruction, calibration, temporal smoothing, replay model, solver handoff, AR/overlay hooks Inspect the retained face-placement, cube-string assembly, and optional two-opposite-corner comparison adjunct slice only in relation to the landed qbr, rubix-cube-solver, and first-party correction-stack owners, existing first-party surfaces, and any unresolved narrower reopen gaps. whether any narrower face-placement, cube-string assembly, and optional two-opposite-corner comparison adjunct gap remains after the landed qbr, rubix-cube-solver, and first-party correction-stack owners and the existing first-party surfaces. Retain only as the closed face-placement, cube-string assembly, and optional two-opposite-corner comparison adjunct beneath the landed qbr, rubix-cube-solver, and first-party correction-stack owners. No default widening packet is open; any future work must start from the landed owners and narrower gap proof. Keep subordinate to qbr and rubix-cube-solver inside the current recognition stack. Use only for bounded cross-checking or disagreement reporting; do not form a separate recognition silo or reopen primary recognition ownership. Integrate here means: only a narrower first-party widening if a concrete owner-side gap is later proven. 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. No cross-project transfer by default This row is already closed as a retained bounded row. Reuse should start only from narrower owner-side gap proof, not generic transfer framing. 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. Closed retained-boundary note + explicit no-default-widening posture + narrower reopen criteria. 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 in canon only as a closed retained face-placement, cube-string assembly, and optional two-opposite-corner comparison adjunct beneath the landed qbr, rubix-cube-solver, and first-party correction-stack owners; reopen only through narrower gap proof, not generic implementation routing. Closed retained face-placement, cube-string assembly, and optional two-opposite-corner comparison adjunct row beneath the landed qbr, rubix-cube-solver, and first-party correction-stack owners; no default widening packet is open for the current slice. Audit cahidenes/rubiks-cube-solver only as a closed retained face-placement, cube-string assembly, and optional two-opposite-corner comparison adjunct row for HyperTwist. Validate that it remains bounded beneath the landed qbr, rubix-cube-solver, and first-party correction-stack owners and identify narrower reopen criteria only; do not frame it as a fresh implementation candidate or standalone owner lane. 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. selected_not_live_permissive_candidate phase2rc_recognition_adjunct_gap_eval_only Phase 2R-C plus the 2026-05-27 recognition-comparison adjunct hierarchy clarification are closed. Retain only as a narrow face-placement, cube-string assembly, and optional two-opposite-corner comparison adjunct beneath the landed qbr, rubix-cube-solver, and correction-stack owners; no default widening packet is open.
10 tentone/rubix-solver https://github.com/tentone/rubix-solver HyperTwist Locked Strategic Donor Retained native quad and color comparison adjunct P1 56 9212 5.0 148.0 174.0 high This row is already closed for its current justified retained slice. Preserve the retained native quad-sorting, square-mask color sampling, center-color face labeling, and face-state comparison adjunct beneath the landed qbr, rubix-cube-solver, and first-party correction-stack owners, and reopen only if a narrower gap is later proven. integrate direct Confirm that tentone/rubix-solver remains a closed retained native quad-sorting, square-mask color sampling, center-color face labeling, and face-state comparison adjunct beneath the landed qbr, rubix-cube-solver, and first-party correction-stack owners, and record only narrower reopen criteria, if any. image pipeline, detection heuristics/models, cube-state reconstruction, calibration, temporal smoothing, replay model, solver handoff, AR/overlay hooks Inspect the retained native quad-sorting, square-mask color sampling, center-color face labeling, and face-state comparison adjunct slice only in relation to the landed qbr, rubix-cube-solver, and first-party correction-stack owners, existing first-party surfaces, and any unresolved narrower reopen gaps. whether any narrower native quad-sorting, square-mask color sampling, center-color face labeling, and face-state comparison adjunct gap remains after the landed qbr, rubix-cube-solver, and first-party correction-stack owners and the existing first-party surfaces. Retain only as the closed native quad-sorting, square-mask color sampling, center-color face labeling, and face-state comparison adjunct beneath the landed qbr, rubix-cube-solver, and first-party correction-stack owners. No default widening packet is open; any future work must start from the landed owners and narrower gap proof. Keep subordinate to qbr and rubix-cube-solver inside the current recognition stack. Use only for bounded native comparison, side-by-side validation, or disagreement reporting; do not form a separate recognition silo or promote the local solve shell. Integrate here means: only a narrower first-party widening if a concrete owner-side gap is later proven. 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. No cross-project transfer by default This row is already closed as a retained bounded row. Reuse should start only from narrower owner-side gap proof, not generic transfer framing. 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. Closed retained-boundary note + explicit no-default-widening posture + narrower reopen criteria. 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 in canon only as a closed retained native quad-sorting, square-mask color sampling, center-color face labeling, and face-state comparison adjunct beneath the landed qbr, rubix-cube-solver, and first-party correction-stack owners; reopen only through narrower gap proof, not generic implementation routing. Closed retained native quad-sorting, square-mask color sampling, center-color face labeling, and face-state comparison adjunct row beneath the landed qbr, rubix-cube-solver, and first-party correction-stack owners; no default widening packet is open for the current slice. Audit tentone/rubix-solver only as a closed retained native quad-sorting, square-mask color sampling, center-color face labeling, and face-state comparison adjunct row for HyperTwist. Validate that it remains bounded beneath the landed qbr, rubix-cube-solver, and first-party correction-stack owners and identify narrower reopen criteria only; do not frame it as a fresh implementation candidate or standalone owner lane. 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 Practical working assumption remains MIT from README and repo presentation, but the checked mirror lacks a bundled top-level license file. Keep this row permissive-active only as a subordinate recognition comparison adjunct, and capture the final authoritative upstream license text before any direct vendoring. 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. medium readme-only-license-capture-before-direct-vendoring yes v6.3_final_source_of_truth Normalized legacy candidate-core wording to dossier-backed strategic-donor posture on 2026-04-25. selected_not_live_permissive_candidate phase2rc_recognition_adjunct_gap_eval_only Phase 2R-C plus the 2026-05-27 recognition-comparison adjunct hierarchy clarification are closed. Retain only as a narrow native quad-sorting, square-mask color sampling, center-color face labeling, and face-state comparison adjunct beneath the landed qbr, rubix-cube-solver, and correction-stack owners; no default widening packet is open.
11 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 This row is already live for its current justified slices. Preserve the landed persisted coaching, weighted sampling, method exploration, and BLD-domain training-session boundaries, and widen only through owned HyperTwist work. integrate direct Validate the current first-party owner boundaries for Lykos/cube_trainer and record any narrower owned widening targets that remain after the landed persisted-coaching slice. Landed persisted coaching, weighted sampling, method exploration, and BLD-domain training-session boundaries as live first-party material. Inspect current first-party persisted-coaching owner boundaries, retained adjacent training-foundation and timer families, and unresolved owned widening targets only. Which remaining persisted-coaching or weighted-sampling gaps, if any, are not already covered by the landed HyperTwist code and the current cube_trainer preserve slice? Preserve as the landed first-party persisted-coaching owner lane. Start any future widening from owned HyperTwist surfaces, the live training stack, FEATURE_REGISTRY, ROADMAP, and REPO_LICENSE_TRACKING; do not route work through donor-extraction framing. Treat current first-party HyperTwist code as the owner. Keep Alg-Trainer as the broader training-foundation owner, KubeTimr as the timer substrate owner, and CubeDesk as adjacent trainer-session and smart-device workflow composition rather than donor merge targets for the already landed slice. Repurpose here means: ordinary owned enhancement of the landed persisted-coaching owner lane, not external donor harvesting. Owned widening only The row is already live inside HyperTwist. Further work should start from first-party owner surfaces, feature registry, roadmap, license tracking, and landed packet authority rather than donor-transfer or merger-thesis framing. 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. Owner-boundary note + owned widening criteria + explicit no-donor-thesis posture. 1) Which landed persisted-coaching owner boundaries are already closed 2) Which narrower owned widening targets, if any, remain 3) Which adjacent live or retained rows stay outside the landed slice 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 an already-landed first-party persisted-coaching owner lane and route all future work through owned widening. Already-landed persisted-coaching owner row for weighted sampling, method exploration, and BLD-domain session families; no donor thesis remains for the current slice. Audit Lykos/cube_trainer only as an already-landed permissive owner lane for HyperTwist. Validate current persisted-coaching owner boundaries and identify owned widening targets only; do not frame it as a donor-merge candidate. 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. Already landed: start from first-party owner surfaces and landed preserve authority, not donor-transfer framing. 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. implemented_live_permissive landed_permissive_preserve Phase 1R closed. Preserve as a landed first-party permissive lane; keep notices and attribution visible and widen only through ordinary owned enhancement work.
13 poliva/cubedex https://github.com/poliva/cubedex HyperTwist Locked Strategic Donor Training / timing layer P1 59 9215 15.0 145.0 171.0 high Retain the repo only as restrictive comparison context. Preserve smartcube-aware practice-shell, review or SRS UX, recognition-versus-execution timing presentation, and local stats-history comparison value while excluding owner, donor, or default clean-room-next assumptions. integrate direct Validate that poliva/cubedex remains restrictive comparison context only and record the exact smartcube-aware practice-shell, review or SRS, timing-presentation, and local stats-history behaviors worth preserving for comparison. Smartcube-aware practice-shell behavior, review or SRS UX, recognition-versus-execution timing presentation, and local stats-history comparison material only. Inspect practice-shell behavior, review or SRS UX, recognition-versus-execution timing presentation, and local stats-history surfaces as comparison material only. Which smartcube-aware practice-shell, review or SRS, timing-presentation, and local stats-history behaviors remain useful only as restrictive comparison context beneath the landed owners? Keep only as restrictive comparison context for smartcube-aware practice-shell behavior, review or SRS UX, recognition-versus-execution timing presentation, and local stats-history comparison; do not treat it as a live owner or a default clean-room next row. Keep behind the landed KubeTimr timer owner, CubeDesk trainer-session owner, broader training foundations, and current first-party training and review-plan owners. Reopen only if a narrower first-party practice or review gap is explicitly proven. Repurpose here means: preserve comparison context for practice-shell, review, timing-presentation, and local stats-history behavior only. Restrictive comparison only Retain only as restrictive comparison, oracle, acceptance-test, or planning input beneath the landed owners. 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. Comparison-context note + bounded retained behaviors + explicit no-default-clean-room boundary. 1) What specific smartcube practice and review comparison value remains in poliva/cubedex 2) What must stay comparison-only beneath the landed owners 3) Which bounded behavior targets are still worth preserving as reference 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 only as restrictive comparison context beneath the landed timer, trainer-session, and training-stack owners. Restrictive smartcube trainer shell with bounded comparison value but no surviving live-owner or default clean-room-next posture. Audit poliva/cubedex only as restrictive comparison context for HyperTwist. Do not recommend donor promotion or a default clean-room start. Extract only the bounded comparison behaviors that remain useful beneath the landed timer, trainer-session, and training-stack owners. HT_training_stack_0016 HT_training_stack poliva/cubedex 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 2 145.0 license_unknown_pending reverse_engineer_preferred No explicit permissive license is visible in the current checked mirror. Retain this repo only as restrictive comparison context for smartcube-aware practice-shell behavior, review/SRS workflow presentation, recognition-versus-execution timing presentation, and local stats/history comparison; implement any strategically necessary behavior only from scrubbed first-party specifications if a narrower gap is later proven. Reference only: restrictive comparison context for smartcube-aware practice-shell, review, timing-presentation, and local stats-history behavior; do not plan direct incorporation or default clean-room reopening. Do not incorporate source directly without a confirmed license grant. Yes - this is the preferred path if a narrower smartcube practice/review slice later proves strategically necessary. medium no-license-clean-room-benchmark yes v6.3_final_source_of_truth Assigned from legacy HY_misc to HT_training_stack during cluster normalization on 2026-04-25. not_live_reference_or_discard_candidate phase0r_reference_benchmark_or_discard_eval Phase 1R plus the 2026-05-27 smartcube practice/review/SRS hierarchy clarification are closed. Retain only as restrictive comparison context for smartcube-aware practice-shell behavior, review/SRS UX, recognition-versus-execution timing presentation, and local stats/history comparison; do not treat it as a live owner or a default clean-room next row.
14 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. Reference only Retain only as benchmark, oracle, acceptance-test, comparison, research, or clean-room-later 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-3.0 and remains the primary restrictive timer, stats, scramble, and smart-device benchmark. Use it for behavioral parity and acceptance criteria, not direct source incorporation. Reference only: benchmark timer, statistics, scramble, and smart-device 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. not_live_reference_or_discard_candidate phase0r_reference_benchmark_or_discard_eval Packet 0R-E closed. Retain as the primary restrictive timer/stats/scramble/smart-device benchmark and future clean-room timer-pattern oracle.
15 cutelyaware/magiccube4d https://github.com/cutelyaware/magiccube4d/tree/master HyperTwist Locked Strategic Donor Implemented legacy 4D boundary lane P1 7463 9218 49.0 122.0 137.0 medium This row is already live for its current justified slice. Preserve the landed legacy 4D interaction, history, macro, and provenance-boundary lane, and widen only through owned HyperTwist work with visible attribution and provenance obligations kept explicit. integrate moderate modification Validate the current first-party owner boundaries for cutelyaware/magiccube4d and record any narrower owned widening targets that remain after the landed legacy 4D interaction/history/macro and provenance-boundary slice. Landed legacy 4D interaction, history, macro, topology-reference, view-controller, and visible attribution/upstream-link/MyMath provenance-boundary notes as live first-party material. Inspect current first-party legacy 4D interaction/history/macro and provenance-boundary owner boundaries, retained adjacent higher-dimensional families, and unresolved owned widening targets only. Which remaining legacy 4D interaction/history/macro or provenance-boundary gaps, if any, are not already covered by the landed HyperTwist code and the current magiccube4d preserve slice? Preserve as the landed first-party legacy 4D interaction/history/macro and provenance-boundary owner lane. Start any future widening from owned HyperTwist surfaces, FEATURE_REGISTRY, ROADMAP, REPO_LICENSE_TRACKING, and the landed Phase 4R-B packet; do not route work through donor-extraction framing. Treat current first-party HyperTwist code as the owner. Keep Hyperspeedcube as the higher-dimensional runtime anchor and later MagicTile topology/macro widening as adjacent owners rather than donor merge targets for the already landed slice. Repurpose here means: ordinary owned enhancement of the landed legacy 4D interaction/history/macro and provenance-boundary lane, not external donor harvesting. Owned widening only The row is already live inside HyperTwist for its bounded boundary-sensitive slice. Further work should start from first-party owner surfaces, feature registry, roadmap, license tracking, and landed packet authority rather than donor-transfer or merger-thesis framing. 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. Owner-boundary note + owned widening criteria + explicit landed boundary-sensitive preserve posture. 1) Which landed legacy 4D boundary owner slices are already closed 2) Which narrower owned widening targets, if any, remain 3) Which adjacent live higher-dimensional rows stay outside the landed slice 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 an already-landed first-party legacy 4D interaction/history/macro and provenance-boundary owner lane and route all future work through owned widening while keeping attribution and provenance obligations explicit. Already-landed legacy 4D interaction/history/macro and provenance-boundary grounding row; no donor thesis remains for the current slice. Audit cutelyaware/magiccube4d only as an already-landed boundary-sensitive owner lane for HyperTwist. Validate current legacy 4D interaction/history/macro and provenance-boundary owner boundaries and identify owned widening targets only; do not frame it as a donor-merge candidate. 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 custom broad-use license is operationally usable, and the justified HyperTwist slice is already implemented in first-party code. Keep visible attribution, upstream-link, notice retention, and MyMath provenance obligations explicit in future widening. Already landed boundary-sensitive: start from first-party outputs and explicit attribution/provenance notes; do not reopen raw donor-merger framing by default. Preserve visible attribution, upstream link, notice retention, and the MyMath provenance caveat where applicable. Usually unnecessary unless you later replace a narrow legacy helper or provenance-boundary surface for architectural reasons. high implemented-attribution-provenance-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. implemented_live_boundary_sensitive landed_boundary_sensitive_preserve Phase 4R-B is closed. Preserve as a landed boundary-sensitive first-party lane; keep attribution, upstream-link, and provenance notes explicit and widen only through ordinary owned enhancement work.
16 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 Validate the current first-party owner boundaries for roice3/Magic120Cell and record any narrower owned widening targets that remain after the landed Phase 6R-I slice beneath the retained Hyperspeedcube runtime anchor. puzzle model, learning flow, UX loops, data schema, replay/export, plugin/hooks Inspect current first-party 120-cell family runtime-profile and persistence boundary, the retained Hyperspeedcube anchor relation, retained broader MagicTile family context, and unresolved owned widening targets only. 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. Owner-boundary note + owned widening criteria + explicit no-donor-thesis posture. 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 only as an already-landed permissive family owner lane for HyperTwist. Validate current owner boundaries and identify owned widening targets only; do not frame it as a donor-merge candidate. 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 its current justified 120-cell family runtime slice is already implemented in first-party HyperTwist code beneath the retained Hyperspeedcube runtime anchor. Further work should be ordinary owned widening from landed packet authority, not donor-transfer framing. Already landed: start from first-party 120-cell family owner surfaces plus landed packet authority beneath the retained Hyperspeedcube anchor. Preserve MIT notices and attribution where required. Usually unnecessary unless later replacing a narrow seam is cleaner than carrying the upstream code. high implemented-specialized-family-owner 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. implemented_live_permissive landed_permissive_preserve Later Phase 6R-I preserve sequence closed for the bounded family slice. Preserve as the landed first-party 120-cell family runtime-profile and persistence lane beneath the retained hyper runtime anchor; start future widening from ROADMAP.md, FEATURE_REGISTRY.md, REPO_LICENSE_TRACKING.md, and the landed Phase 6R-I packet.
17 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 Validate the current first-party owner boundaries for roice3/MagicCube5D and record any narrower owned widening targets that remain after the landed Phase 6R-J slice beneath the retained Hyperspeedcube runtime anchor. puzzle model, learning flow, UX loops, data schema, replay/export, plugin/hooks Inspect current first-party 5D family runtime-profile and persistence boundary, the retained Hyperspeedcube anchor relation, retained broader MagicTile family context, and unresolved owned widening targets only. 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. Owner-boundary note + owned widening criteria + explicit no-donor-thesis posture. 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 only as an already-landed permissive family owner lane for HyperTwist. Validate current owner boundaries and identify owned widening targets only; do not frame it as a donor-merge candidate. 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 its current justified 5D family runtime slice is already implemented in first-party HyperTwist code beneath the retained Hyperspeedcube runtime anchor. Further work should be ordinary owned widening from landed packet authority, not donor-transfer framing. Already landed: start from first-party 5D family owner surfaces plus landed packet authority beneath the retained Hyperspeedcube runtime anchor. Preserve MIT notices and attribution where required. Usually unnecessary unless later replacing a narrow seam is cleaner than carrying the upstream code. high implemented-specialized-family-owner 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. implemented_live_permissive landed_permissive_preserve Later Phase 6R-J preserve sequence closed for the bounded family slice. Preserve as the landed first-party 5D family runtime-profile and persistence lane beneath the retained hyper runtime anchor; start future widening from ROADMAP.md, FEATURE_REGISTRY.md, REPO_LICENSE_TRACKING.md, and the landed Phase 6R-J packet.
18 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. Historical comparison only Retain only as discarded historical comparison context; do not plan donor, merge, or clean-room reopening from this row. 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 was discarded from the active HyperTwist retained set because its strongest XR collaboration value is off-domain and already superseded by stronger retained rows. Reference only: discarded historical comparison context for XR collaboration patterns; do not plan direct 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. not_live_reference_or_discard_candidate phase0r_reference_benchmark_or_discard_eval Packet 0R-E closed. Discard from the active retained set; its XR collaboration value is off-domain and already superseded by stronger retained rows.
19 brianpeiris/RiftSketch https://github.com/brianpeiris/RiftSketch HyperTwist Reserve Bench Reference-only immersive live-coding benchmark P3 7468 9223 51.0 119.0 134.0 medium Retain the interaction shell only as historical comparison context. For this repo class, preserve live sketch-loop, world-space monitor/text-area placement, and WebXR scene-update patterns as design reference while excluding donor, calibration, or product-shell assumptions. future candidate architecture only Validate that RiftSketch remains reference-only and record the specific immersive live-coding, world-space monitor, and scene-update ideas worth preserving without direct source reuse. Live sketch loop, dynamic code execution, world-space monitor/text-area composition, WebXR session entry, and scene-update behavior as benchmark material only. Inspect README/docs, sketch loop, dynamic code execution, local sketch persistence, text-area/monitor composition, WebXR session entry, and scene interception as benchmark material only. Which live-coding, world-space monitor, text-area, and real-time scene-update patterns are reusable at the behavior level without inheriting the WebXR live-coding shell or reopening an off-topic product lane? Keep in permissive/reference custody. Use only as a benchmark for immersive live-coding, world-space text-entry, and live scene-update interaction ideas; do not merge source into HyperTwist. Do not treat this repo as part of the HyperTwist merge nucleus. If useful, translate isolated live-coding, world-space monitor, and text-entry interaction ideas into first-party browser/XR surfaces without inheriting the product shell. Repurpose here means: abstract live-coding loop, text-entry, world-space monitor, and scene-update interaction ideas into first-party browser/XR surfaces without reusing source. Historical comparison only Retain only as discarded historical comparison context; do not plan donor, merge, or clean-room reopening from this row. 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 + live-coding interaction salvage list + clear do-not-incorporate boundary. 1) What specific benchmark value remains in brianpeiris/RiftSketch 2) What must stay benchmark-only and off-mission 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 immersive live-coding benchmark; its value is in live-coding, world-space monitor, text-entry, and scene-update ideas, not donor code. Useful MIT WebXR live-coding and world-space monitor benchmark for immersive tooling patterns, but explicitly off-topic to HyperTwist's retained product scope. Audit brianpeiris/RiftSketch only as a reference-only immersive live-coding benchmark for HyperTwist. Do not recommend direct incorporation. Extract live-coding loop, world-space monitor, text-entry, and scene-update interaction ideas only. 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 pattern_only_preferred The repo is MIT but was discarded from the active retained set because its immersive live-coding shell is off topic to HyperTwist's retained product scope. Reference only: discarded historical comparison context for immersive live-coding, world-space monitor, and text-entry interaction patterns; do not plan direct incorporation. 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. not_live_reference_or_discard_candidate phase0r_reference_benchmark_or_discard_eval Packet 0R-E closed. Discard from the active retained set; its immersive live-coding value is off-topic and already superseded by stronger retained browser/XR, capture, and export rows.
128
129
130
131
132
133
134
136
137
138
139
140
141
142