Align boundary-sensitive row source truth

docs/HYPERTWIST_LIVE_BOUNDARY_SENSITIVE_ROWS_SOURCE_ALIGNMENT_2026-05-28.md

@@ -0,0 +1,59 @@
+# HyperTwist Live Boundary-Sensitive Rows Source Alignment - 2026-05-28
+
+## Status
+
+This document closes the row-source truth gap for the already-landed
+boundary-sensitive rows whose `v6.3` operational, `Phase G`, and source-audit
+layers were still using donor-era wording after the later live-lane,
+provenance-board, and compliance-boundary reconciliations.
+
+## Affected rows
+
+- `cubing/cubing.js`
+- `cutelyaware/magiccube4d`
+- `PostHog/posthog`
+
+## Current judgment
+
+- these rows are already landed for their current bounded boundary-sensitive
+  slices
+- the stale layer was the row-source pack still framing them as donor
+  selection, promotion, or salvage targets rather than closed owner or
+  grounding lanes
+- no product code change is justified from this pass
+- no boundary doctrine changed from this pass
+
+## Required row-source posture
+
+For these rows the source pack must now say:
+
+- `cubing/cubing.js` is already landed for the exact classic-cubing
+  semantic/runtime adapter lane and the explicit practical `MPL` and notice
+  boundary grounding beneath it
+- `cutelyaware/magiccube4d` is already landed for the exact legacy `4D`
+  interaction/history/macro lane and the visible-attribution/upstream-link and
+  `MyMath` provenance boundary beneath it
+- `PostHog/posthog` is already landed for the exact control-plane telemetry,
+  replay-diagnostic, scheduled-change, early-access, and feature-governance
+  lane, with the `MIT`-outside-`ee/` boundary kept explicit
+- future work starts from owned HyperTwist surfaces and landed preserve
+  authority, not fresh donor promotion or raw-mirror routing
+
+## Source basis
+
+- `C:\HyperTwist\docs\HYPERTWIST_CUBING_JS_REFERENCE_INCORPORATION_PROVENANCE_BOARD_2026-05-27.md`
+- `C:\HyperTwist\docs\HYPERTWIST_MAGICCUBE4D_REFERENCE_INCORPORATION_PROVENANCE_BOARD_2026-05-27.md`
+- `C:\HyperTwist\docs\HYPERTWIST_POSTHOG_REFERENCE_INCORPORATION_PROVENANCE_BOARD_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 4R-A`, `4R-B`, and `4R-D` 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 future donor-candidate rows anymore.
+
+They are already integrated for their current justified boundary-sensitive
+slices, and the row-source pack must now describe them that way.

docs/repo_portfolio_unified_source_audit_v6_3.csv

@@ -17,15 +17,9 @@
 "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."
-"cubing/cubing.js","https://github.com/cubing/cubing.js","HyperTwist","Locked Strategic Donor","Boundary-sensitive classic-cubing semantics and rendering donor","P1","24","9207","7.0","152.0","185.0","high","Keep the core engine or major subsystem mostly intact; change wrappers, branding, storage/auth, and integration seams so it becomes a first-class part of the target stack. For this repo class, that usually means preserving scene/layout primitives and replacing surrounding data models or backend assumptions.","integrate","direct","Validate whether cubing/cubing.js truly deserves its current foundation-tier role for HyperTwist; extract the irreducible core abstractions, extension points, and transplantable subsystems.","state representation, move engine, notation parser, solver interfaces, renderer/projection abstraction, serialization/save formats, input mapping, performance/accuracy tradeoffs","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for reusable canvas/editor components, design tokens, state models, keyboard shortcuts, drag/drop, accessibility, virtualization, and polished interaction patterns.","Inspect scene graph/canvas data model; layout primitives; component library; keyboard/gesture interactions; import/export schema; theming; plugin or extension hooks.","Integrate as a ui / design / frontend subsystem for HyperTwist. Preserve the strongest existing pieces — component library, canvas/animation engine, interaction patterns, layout/state models, accessibility hooks, theming, editor widgets — and expose them behind a portfolio-stable interface. Wire first into HactarCE/Hyperspeedcube, then into kkoomen/qbr for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: HactarCE/Hyperspeedcube, kkoomen/qbr.","Repurpose here means: turn it into a frontend interaction donor, canvas/editor pattern library, or polished shell layer on top of existing anchors.","project-local anchor","base + donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","shared portfolio utility","augmenter","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cross-project transfer candidate","future merger","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","VectorShell | HyperTwist | ScriptoriumAI","This capability is broadly portable across the portfolio because interaction, orchestration, and shell/UI patterns can be shared with thin domain adapters.","Keep current tier unless source audit reveals architectural shallowness, hard-coded assumptions, missing extension points, or brittle internals.","Downgrade if core capabilities are thinner than claimed, architecture is too brittle or narrow, maintenance reality is poor, or the differentiating thesis collapses under code inspection.","Architecture note + salvage map + integration recipe + reclassification verdict","1) Confirmed visible capabilities
-2) Hidden capabilities found only in source
-3) Best salvageable modules/files/packages
-4) Integration path into target project
-5) Repurpose path outside the original thesis
-6) Best merge partners and exact coupling seam
-7) Reasons to promote / retain / demote
-8) Confidence change after source audit
-9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo; Relevant project-locked board sheet. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep as the canonical classic-cubing semantics and interop donor, but only through its practical MPL path or bounded adapter/package consumption.","Dual MPL/GPL classic-cubing anchor with strong donor value, but not a carefree private-source fork candidate.","Audit cubing/cubing.js as a interface / visualization / shell surface candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect scene graph/canvas data model; layout primitives; component library; keyboard/gesture interactions; import/export schema; theming; plugin or extension hooks. Decide whether the best extraction path is direct and whether it belongs as foundation engine / visualization donor. Test the three merger paths in order: 1) project-local anchor [base + donor]; 2) shared portfolio utility [augmenter]; 3) cross-project transfer candidate [future merger]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_cube_semantics_0001","HT_cube_semantics","cubing/cubing.js","","","","","","","Original global P0-P3 source audit retained","MPL-2.0 OR GPL-3.0-or-later","known_from_reference_material","uploaded_reference_docs","yes","hypertwist_and_scriptoriumai","HyperTwist","HyperTwist & ScriptoriumAI.txt","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","Existing v5 row reaffirmed or widened by v6 supplemental intake.","v6_unified_source_of_truth_pack","2","1","152.0","mixed_or_boundary_sensitive_known","bounded_sidecar_or_selective_reimplementation","The repo is dual-licensed MPL-2.0 OR GPL-3.0-or-later. HyperTwist can consume it as a package or bounded adapter under the MPL side, but should avoid a carefree deep private source fork of upstream files.","Prefer package/dependency consumption or a bounded adapter seam under the MPL side; avoid deep private forks of upstream source files.","Preserve MPL notices and publish modifications to MPL-covered files when distribution obligations apply; avoid assuming the GPL side is the intended operational path.","Only if you later need to replace narrow upstream-covered seams with first-party equivalents or avoid carrying MPL-governed source modifications.","high","dual-license-boundary-review","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Assigned to HT_cube_semantics during cluster normalization on 2026-04-25.","implemented_live_boundary_sensitive","landed_boundary_sensitive_preserve","Phase 4R-A closed. Preserve as the landed first-party classic-cubing semantic/runtime adapter lane through explicit MPL-aware dependency or adapter use; keep notices and publication duties explicit before any future direct upstream file modification."
+"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."
 "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."
@@ -62,15 +56,9 @@
 "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."
-"cutelyaware/magiccube4d","https://github.com/cutelyaware/magiccube4d/tree/master","HyperTwist","Locked Strategic Donor","Top-tier 4D interaction, history, and macro donor with attribution obligations","P1","7463","9218","49.0","122.0","137.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving generalized puzzle/state/render logic while building a new application shell around it.","repurpose","moderate modification","Determine whether cutelyaware/magiccube4d should stay donor/merge-tier for HyperTwist, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","puzzle model, learning flow, UX loops, data schema, replay/export, plugin/hooks","Inspect package manifests, README/docs, src tree, examples, tests, CI workflows, config files, migrations/schemas, and hidden feature flags or experimental modules. Look for higher-dimensional state/notation representations, projection math, renderer abstractions, puzzle serialization, controls, and replay/training hooks.","Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.","Integrate as a hypercubing / nD simulation subsystem for HyperTwist. Preserve the strongest existing pieces — nD state model, move notation, renderer, projection controls, solver/traversal logic, puzzle serialization, replay — and expose them behind a portfolio-stable interface. Wire first into HactarCE/Hyperspeedcube, then into cubing/cubing.js for orchestration, visualization, or data exchange.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: HactarCE/Hyperspeedcube, cubing/cubing.js, tao-yu/Alg-Trainer.","Repurpose here means: turn it into a higher-dimensional renderer/simulator donor and shared interaction grammar for HyperTwist and long-horizon VectorShell.","HactarCE/Hyperspeedcube","foundation + donor","Use this repo against the partner as an augmenting layer; preserve the partner as the likely base and mine this repo for capabilities that improve breadth, UX, or specialization.","cubing/cubing.js","3D engine + notation/state donor","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","tao-yu/Alg-Trainer","training UX donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","VectorShell | ScriptoriumAI","VectorShell can borrow spatial/rendering and perception primitives; ScriptoriumAI can borrow tutorial/educational visualization patterns rather than the full engine.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
-2) Hidden capabilities found only in source
-3) Best salvageable modules/files/packages
-4) Integration path into target project
-5) Repurpose path outside the original thesis
-6) Best merge partners and exact coupling seam
-7) Reasons to promote / retain / demote
-8) Confidence change after source audit
-9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep as one of the most important legacy 4D interaction donors; the dossier-backed custom broad-use license is operationally usable, but attribution and provenance obligations must stay explicit.","Custom broad-use donor with strong 4D interaction/history/macro value and explicit attribution/provenance obligations.","Audit cutelyaware/magiccube4d as a hypercubing / nD engine candidate for HyperTwist. Do not stop at README-level features. Inspect: Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations. Decide whether the best extraction path is moderate modification and whether it belongs as subsystem donor / simulation donor. Test the three merger paths in order: 1) HactarCE/Hyperspeedcube [foundation + donor]; 2) cubing/cubing.js [3D engine + notation/state donor]; 3) tao-yu/Alg-Trainer [training UX donor]. Return hidden modules, reusable schemas, protocol layers, plugin hooks, render/state models, datasets/test fixtures, and any subsystem stronger than the visible product shell.","HT_hyper_engine_0003","HT_hyper_engine","cutelyaware/magiccube4d","","","","","","","Original global P0-P3 source audit retained","Custom broad-use license with attribution requested","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","122.0","mixed_or_boundary_sensitive_known","direct_incorporation_ok","The repo is operationally usable because the custom license explicitly allows use, modification, and redistribution, but attribution and provenance obligations must be preserved and tracked.","Direct donor use is acceptable with explicit attribution and provenance tracking; keep the MyMath.java provenance note visible in license tracking.","Preserve the custom license text, requested attribution, and the provenance note for utility code with referenced GPL lineage.","Usually unnecessary unless later isolating a narrow seam is cleaner than carrying the legacy code directly.","medium","custom-license-attribution-review","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Corrected on 2026-04-25 from stale unknown-license merge-bench posture to dossier-backed usable custom-license donor status.","implemented_live_boundary_sensitive","landed_boundary_sensitive_preserve","Phase 4R-B closed. Preserve as the landed attributed legacy 4D interaction, history, macro, topology-reference, and provenance-boundary lane beneath the Hyperspeedcube anchor; start future widening from the live-lane audit, then Phase 4R-B, then REPO_LICENSE_TRACKING.md."
+"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."
 "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
@@ -161,15 +149,9 @@
 7) Reasons to promote / retain / demote
 8) Confidence change after source audit
 9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","Keep as a top-tier non-Euclidean geometry and topology donor for HyperTwist; the dossier-backed MIT posture and source richness justify promotion above the old donor-bench treatment.","MIT donor with unusually strong non-Euclidean tiling, topology, and generalized twist infrastructure value.","Audit roice3/MagicTile 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_0007","HT_hyper_engine","roice3/magictile","","","","","","","Original global P0-P3 source audit retained","MIT","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","88.0","permissive_or_noncopyleft_known","direct_incorporation_ok","The repo is MIT and its current justified topology and transform-aware macro slice is already implemented in first-party HyperTwist code. Further work should be ordinary owned widening from landed packet authority, not donor-transfer framing.","Already landed: start from first-party topology and macro owner surfaces plus landed packet authority, and keep the broader host-shell remainder deferred unless a later owned widening is justified.","Preserve MIT notices and attribution where required.","Usually unnecessary unless later replacing a narrow seam is cleaner than carrying the upstream code.","high","implemented-bounded-owner","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Assigned from legacy HY_misc to HT_hyper_engine during cluster normalization on 2026-04-25.","implemented_live_permissive","landed_permissive_preserve","Later Phase 6R-D/T preserve sequence closed for the bounded retained slice. Preserve as the landed first-party tiling topology, geometry-family, and transform-aware macro remapping lane; start future widening from ROADMAP.md, FEATURE_REGISTRY.md, REPO_LICENSE_TRACKING.md, and the repo-specific landed Phase 6R packets, while broader host-shell ownership stays deferred."
-"PostHog/posthog","https://github.com/PostHog/posthog","HyperTwist","Donor Bench","Adjacency / future transfer","P2","7492","9247","20.0","72.0","81.0","medium","Retain the valuable internal engine, but expect to replace UI/product shell, adapt schemas/APIs, and refactor boundaries so it can plug into the target anchors cleanly. For this repo class, that usually means preserving calibration/detection/state-reconstruction logic while replacing camera UX and integration surfaces.","repurpose","moderate modification","Determine whether PostHog/posthog should stay donor/merge-tier for HyperTwist, be promoted, or be demoted; identify concrete salvageable modules and best merge path.","telemetry and event schemas, replay product boundaries, feature-flag governance, diagnostics, service slices, hidden modules","Inspect package manifests, README/docs, product slices, services, tests, migrations/schemas, and hidden feature flags or experimental modules. Look for replay diagnostics, replay query surfaces, feature-flag governance, activity logs, event schemas, service boundaries, and MIT versus ee/ path splits.","Inspect replay routes and deep links; replay diagnostics; feature-flag CRUD, dependencies, and evaluation; telemetry and event schemas; product and service boundaries; MIT versus ee path splits.","Repurpose selected subsystems rather than the whole product. Mine the repo for telemetry and event schemas, replay diagnostics, replay query surfaces, feature-flag governance, activity logs, and product/service boundary patterns; keep what materially shortens build time, but rebind data contracts, permissions, storage, and deployment to the HyperTwist architecture. Best first pairing order: HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr.","Consolidate under the Hyperspeedcube + cubing.js + qbr nucleus, not beside it as a separate silo. Normalize data contracts, auth/permissions, storage, and telemetry; then attach as a service, plugin, canvas layer, trainer, or analysis module. Descending combination order: HactarCE/Hyperspeedcube, cubing/cubing.js, kkoomen/qbr.","Repurpose here means: turn it into a telemetry spine, replay diagnostics donor, feature-governance donor, or control-plane integration layer.","kkoomen/qbr","foundation + perception donor","Use this repo against the partner as an augmenting layer; preserve the partner as the likely base and mine this repo for capabilities that improve breadth, UX, or specialization.","vivaansinghvi07/rubix-cube-solver","perception + replay donor","Treat this pairing as a candidate donor merge rather than a replacement decision; inspect module boundaries to determine which side owns the final shell.","cubing/cubing.js","state/render backend","Use the partner for canonical state or rendering abstractions and merge this repo's specialized logic on top.","VectorShell | ScriptoriumAI","VectorShell can borrow spatial/rendering and perception primitives; ScriptoriumAI can borrow tutorial/educational visualization patterns rather than the full engine.","Upgrade if source reveals clean modular architecture, reusable core abstractions, strong adapters/plugins, robust tests, and direct fit to a locked stack.","Demote if reusable value is mostly superficial, undocumented complexity overwhelms salvage value, or higher-ranked repos clearly dominate the same role.","Capability inventory + salvage targets + promotion/demotion verdict","1) Confirmed visible capabilities
-2) Hidden capabilities found only in source
-3) Best salvageable modules/files/packages
-4) Integration path into target project
-5) Repurpose path outside the original thesis
-6) Best merge partners and exact coupling seam
-7) Reasons to promote / retain / demote
-8) Confidence change after source audit
-9) Open questions / blockers","Primary: Phase G v4 board (canonical ranking and current bucket); Operational v3 board filtered to this repo; Merger matrix rows involving this repo; VS Code packet row for this repo, if present. Optional: Cluster narratives row for matching cluster; Bookmark occurrence rows for this repo. Do not attach v1/v2 or preliminary memo unless a judgment conflict, lineage ambiguity, or rationale gap needs arbitration.","PostHog/posthog is placed in Donor Bench for HyperTwist because it best serves the 'Telemetry / replay / feature-governance donor' role; recommended action remains 'repurpose' with repurposing scope 'moderate modification'. Its real retained value is replay diagnostics, flag governance, event-schema thinking, and service-boundary patterns rather than any vision or perception role.","Useful subsystem donor for HyperTwist in telemetry, replay diagnostics, feature flags, event-schema design, and vertical-slice control-plane patterns rather than the core runtime or product shell.","Audit PostHog/posthog as a telemetry / replay / feature-governance candidate for HyperTwist. Do not stop at README-level features. Inspect: replay routes and deep links, replay diagnostics, feature-flag CRUD/dependencies/evaluation, telemetry and event schemas, product/service boundaries, and MIT versus ee/ path splits. Decide whether the best extraction path remains moderate modification and which seams should stay bounded due mixed licensing or mission misfit. Return hidden modules, reusable schemas, protocol layers, plugin hooks, replay/debugging surfaces, and any subsystem stronger than the visible product shell.","HT_control_plane_0001","HT_control_plane","posthog/posthog","","","","","","","Original global P0-P3 source audit retained","MIT outside ee/; enterprise-restricted in ee/","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","72.0","mixed_or_boundary_sensitive_known","bounded_sidecar_or_selective_reimplementation","The repo is mixed-license: MIT outside ee/ and enterprise-restricted inside ee/. Use only clearly MIT paths as bounded telemetry, replay, and feature-governance donor material, and exclude or reimplement enterprise-gated paths.","Use only clearly MIT paths outside ee/ as bounded telemetry, replay, and feature-governance donor surfaces; exclude enterprise paths or reimplement equivalent seams.","Keep MIT notices for reused paths and do not incorporate ee/ without separate commercial rights; verify path provenance before shipping.","Sometimes useful for enterprise-gated or off-mission slices, but not required for clearly MIT paths.","high","mixed-license-path-review-required","no","","","","","","","","","","","","","v6.3_final_source_of_truth","Assigned to HT_control_plane and normalized telemetry/replay/feature-governance wording on 2026-04-25.","implemented_live_boundary_sensitive","landed_boundary_sensitive_preserve","Phase 4R-D closed. Preserve as the landed first-party control-plane telemetry, replay-diagnostic, scheduled-change, early-access, and explicit root-MIT-core-versus-ee/ subtree-compliance lane; start future widening from the live-lane audit, then Phase 4R-D, then REPO_LICENSE_TRACKING.md; keep the explicit ee/ exclusion and mixed-license subtree boundary visible."
+"PostHog/posthog","https://github.com/PostHog/posthog","HyperTwist","Donor Bench","Implemented control-plane boundary lane","P2","7492","9247","20.0","72.0","81.0","medium","This row is already live for its current justified slice. Preserve the landed control-plane telemetry, replay-diagnostic, scheduled-change, early-access, and feature-governance lane, and widen only through owned HyperTwist work with the MIT-outside-ee boundary kept explicit.","integrate","moderate modification","Validate the current first-party owner boundaries for PostHog/posthog and record any narrower owned widening targets that remain after the landed control-plane telemetry, replay-diagnostic, and feature-governance slice.","Landed replay diagnostics, replay segmentation, feature governance, scheduled-change, early-access, and MIT-outside-ee compliance-boundary notes as live first-party material.","Inspect current first-party control-plane telemetry, replay-diagnostic, and feature-governance owner boundaries, retained adjacent replay and browser-support families, and unresolved owned widening targets only.","Which remaining control-plane telemetry, replay-diagnostic, or feature-governance gaps, if any, are not already covered by the landed HyperTwist code and the current PostHog preserve slice?","Preserve as the landed first-party control-plane telemetry, replay-diagnostic, and feature-governance owner lane. Start any future widening from owned HyperTwist surfaces, FEATURE_REGISTRY, ROADMAP, REPO_LICENSE_TRACKING, and the landed Phase 4R-D packet; do not route work through donor-extraction framing.","Treat current first-party HyperTwist code as the owner. Keep replay-shell owners and adjacent browser/control-plane support families separate rather than donor merge targets for the already landed slice.","Repurpose here means: ordinary owned enhancement of the landed control-plane telemetry, replay-diagnostic, and feature-governance 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 control-plane boundary owner slices are already closed
+2) Which narrower owned widening targets, if any, remain
+3) Which adjacent live replay or browser-support 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 control-plane telemetry, replay-diagnostic, and feature-governance owner lane and route all future work through owned widening while keeping the MIT-outside-ee boundary explicit.","Already-landed control-plane telemetry, replay-diagnostic, scheduled-change, early-access, and feature-governance row; no donor thesis remains for the current slice.","Audit PostHog/posthog only as an already-landed boundary-sensitive owner lane for HyperTwist. Validate current control-plane telemetry, replay-diagnostic, and feature-governance owner boundaries and identify owned widening targets only; do not frame it as a donor-merge candidate.","HT_control_plane_0001","HT_control_plane","posthog/posthog","","","","","","","Original global P0-P3 source audit retained","MIT outside ee/; enterprise-restricted in ee/","known_from_reference_material","uploaded_reference_docs","no","","","","Supplemental intake references are advisory only; v6 adjudication remains the source of truth.","Usually indirect","yes","v6 unified all-project source-of-truth pack","v5_carry_forward","","v6_unified_source_of_truth_pack","2","3","72.0","mixed_or_boundary_sensitive_known","bounded_sidecar_or_selective_reimplementation","The repo is mixed-license, and the justified HyperTwist slice is already implemented through landed first-party code using MIT-side semantics and grounding only. Keep all future widening on first-party or clearly MIT-side surfaces outside ee/, and keep enterprise paths excluded by default.","Already landed boundary-sensitive: start from first-party outputs, landed packet authority, and explicit MIT-outside-ee boundary notes; do not reopen raw ee/ source use by default.","Preserve MIT notices where required, keep the enterprise subtree exclusion explicit, and treat any ee/ path as out of scope unless separately reimplemented or licensed.","Usually unnecessary for the current landed slice; reopen only if a narrower first-party widening target truly requires fresh MIT-side-only comparison or clean reimplementation.","high","implemented-ee-boundary-review","yes","","","","","","","","","","","","","v6.3_final_source_of_truth","Assigned to HT_control_plane and normalized telemetry/replay/feature-governance wording on 2026-04-25.","implemented_live_boundary_sensitive","landed_boundary_sensitive_preserve","Phase 4R-D is closed. Preserve as a landed boundary-sensitive first-party lane; keep the MIT-outside-ee boundary explicit and widen only through ordinary owned enhancement work."
 "HactarCE/2x2x2x2-Scrambler","https://github.com/HactarCE/2x2x2x2-Scrambler","HyperTwist","Donor Bench","Implemented Melinda clean-room lane","P2","7496","9251","2.0","63.0","63.0","low-to-medium","This row is already live for its current justified slice. Preserve the landed Melinda state legality, handedness or parity, move-family application, random-state generation, scramble-packet, and flat teaching-projection 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 HactarCE/2x2x2x2-Scrambler and record any narrower owned widening targets that remain after the landed Melinda clean-room slice.","Landed Melinda state legality, handedness or parity, move-family application, random-state generation, scramble-packet, and flat teaching-projection boundaries as live first-party material through the clean-room route.","Inspect current first-party Melinda clean-room owner boundaries, retained adjacent higher-dimensional reference families, and unresolved owned widening targets only.","Which remaining Melinda state, legality, handedness or parity, scramble-packet, or flat projection 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 Melinda 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 HyperTwistCore code as the live owner above the restrictive outputs. Keep magiccube4d as adjacent legacy reference context and broader higher-dimensional runtime ownership with adjacent live lanes rather than donor merge targets for the already landed clean-room slice.","Repurpose here means: ordinary owned enhancement above the landed Melinda 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 Melinda clean-room owner boundaries are already closed
 2) Which narrower owned widening targets, if any, remain
 3) Which adjacent live higher-dimensional rows stay outside the landed slice","Use v6 unified board + P2 tier packet + project design language + relevant family references.","Keep in canon as an already-landed first-party Melinda clean-room owner lane and route all future work through owned widening above the restrictive outputs.","Already-landed Melinda state legality, handedness or parity, move-family, random-state generation, scramble-packet, and flat teaching-projection row through the clean-room route; no open donor thesis remains for the current slice.","Audit HactarCE/2x2x2x2-Scrambler only as an already-landed restrictive clean-room owner lane for HyperTwist. Validate current Melinda owner boundaries and identify owned widening targets only; do not frame it as a fresh donor-merge candidate.","HT_cube_semantics_0004","HT_cube_semantics","hactarce/2x2x2x2-scrambler","supplemental_v6_not_runtime_anchored","","","","","no","v6_unified_source_of_truth_pack","GPL-3.0","known_from_reference_material","uploaded_reference_docs","","","","","","","","","","","","2","3","63.0","mixed_or_boundary_sensitive_known","reverse_engineer_preferred","The upstream repo is GPL-3.0 and 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-E 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."