hypertwist/docs/REPO_LICENSE_TRACKING.md

Repo License Tracking

Created on 2026-04-24

Purpose

This file tracks repo-by-repo licensing determinations for external repos considered for HyperTwist.

It complements, rather than replaces, the policy-level file already present in:

• C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\LICENSETRACKING.md

Use the v6.5 file for project policy categories.

Use this root file for concrete repo-by-repo judgments made during source-backed evaluation.

Authority boundary and placement rule

This root tracker is the canonical place for repo-row legal and provenance detail.

Store here:

• exact repo or package license posture
• repo-specific author attribution requirements
• repo-specific copyright notice preservation requirements
• Apache NOTICE or equivalent redistribution requirements
• asset-level or package-level attribution caveats
• source-basis quirks, mirror gaps, and provenance exceptions

Do not store those details only in:

• C:\HyperTwist\docs\v6_5_deep_manual_pack\HyperTwist\LICENSETRACKING.md

The v6.5 LICENSETRACKING.md file is policy-level only.

It may summarize categories, vocabulary, and current reset rules, but repo-row attribution and other concrete licensing detail must live here.

Packet docs may carry concise implementation-facing licensing snapshots so an integrating instance does not miss the legal posture during handoff.

Those packet snapshots do not replace this file.

Use it for:

• every canonized repo's current license determination, even when the answer is a straightforward MIT, Apache-2.0, or BSD-style permissive case
• custom licenses that are permissive enough to use but still deserve explicit attribution handling
• repos with embedded provenance notes that should be preserved in the implementation record
• exceptions where the practical integration posture differs from a naive MIT / Apache-2.0 / GPL bucket

Do not use it as the primary architecture ledger. The architecture and donor decisions remain in the GPT parse files.

2026-05-14 donor-strength versus route doctrine

This file records legal posture, compliance burden, and route constraints.

It does not decide technical ownership by permissive status alone.

Rule:

• donor strength and legal posture are separate axes
• a restrictive, copyleft, mixed-license, or boundary-sensitive repo can still be the stronger owner for a lane
• if it wins technically, the route may still be clean-room, sidecar, protocol boundary, reference-only, pattern-only, donor-only for later, or explicit non-integration
• harder route does not mean weaker donor
• easier route does not mean better owner

Use packet and retained-set docs for ownership verdicts.

Use this file for legal posture and route constraints after the ownership comparison is made.

2026-05-20 portfolio-census completion rule

A shallow portfolio census is not complete merely because queue order and route posture were frozen.

Required rule:

• when a pass adds or refreshes repo-row queue posture from README-level or similarly shallow inspection, it must also capture the repo-row legal basis in this tracker
• at minimum, that same pass must inspect the best available local license basis for each row:
  • top-level LICENSE, LICENSE.md, LICENSE.txt, or equivalent
  • NOTICE or equivalent redistribution file when present
  • package metadata or README licensing statement only if no stronger local license file exists
• if a row still cannot be fully resolved in the same pass, the pass must list the exact uncovered rows and the reason they remain unresolved
• do not present a portfolio census as complete if newly active or newly queued rows still lack explicit root-tracker coverage

Practical implication:

• README-level queue freezing may be shallow
• repo-row legal tracking may not be skipped at the same time

2026-05-27 generated legal-evidence rule

This root tracker remains the canonical repo-row legal ledger.

The generated legal-evidence bundle is a companion, not a replacement.

Required rule:

• when live mirror custody changes, repo-root legal evidence changes, or a deep-source pass materially refreshes a relied-on repo row, update:
  • C:\HyperTwist\docs\HYPERTWIST_REPO_LICENSE_EVIDENCE_AUDIT_2026-05-27.md
  • C:\HyperTwist\docs\generated\license_audit\HYPERTWIST_REPO_LICENSE_EVIDENCE_AUDIT_2026-05-27.csv
• if a retained repo URL is not publicly resolvable and no local mirror exists, record that as an explicit upstream-unavailable exclusion in the manifest, generated audit bundle, and this root tracker instead of leaving it as an accidental generic missing-path row
• if a missing standalone repo row is only a historical alias and maintained public source surfaces now live elsewhere, convert it into a historical alias row instead of keeping it in the active mirror-restoration queue
• if a manifest row points at a package subpath inside a mirrored monorepo and the parent git root resolves to the same repo URL, normalize that row under the parent root authority in the generated audit rather than treating it as a generic exclusion; keep the package-specific legal/provenance interpretation here in the tracker
• if a repo resolves to MIT from a repo-root license file, capture the exact repo-root MIT text under:
  • C:\HyperTwist\docs\generated\license_audit\MIT_LICENSE_TEXTS_2026-05-27\
• if the MIT call is README-only or metadata-only, capture canonical MIT text there and record the evidence path, source URL, and commit hash in the audit ledger and third-party notices draft
• update the MIT notice draft whenever MIT rows or evidence tiers change:
  • C:\HyperTwist\docs\generated\license_audit\THIRD_PARTY_NOTICES_MIT_DRAFT_2026-05-27.txt
• preserve Apache NOTICE, subtree, package-split, and other repo-row duties here in the root tracker; the generated bundle does not replace repo-row obligation tracking
• rerun the generator in the same pass:
  • C:\HyperTwist\scripts\Write-HyperTwistRepoLicenseEvidenceAudit.ps1

2026-05-13 current HyperTwist implementation truth

Status update on 2026-05-21:

• the current canonical repo-row portfolio count is 75
• all 75 current portfolio rows now have explicit root-tracker coverage
• the current implemented-row count is 29
• the four later restrictive clean-room rows now implemented after the original 2026-05-13 truth block are:
  • cubing/alg.js
  • cubing/twisty.js
  • HactarCE/2x2x2x2-Scrambler
  • kash/cubedesk
• the fifth additional implemented row is the same-day bounded permissive partial row:
  • HactarCE/Hyperspeedcube
• the sixth additional implemented row is the same-day bounded permissive partial row:
  • kkoomen/qbr
• the seventh additional implemented row is the same-day bounded permissive partial row:
  • vivaansinghvi07/rubix-cube-solver
• the eighth additional implemented row is the next-day bounded permissive partial row:
  • roice3/MagicTile
• the ninth additional implemented row is the same-day bounded permissive partial row:
  • SYSTRAN/faster-whisper
• the earlier first-party packet block is now confirmed landed in current code through:
  • d4f4ad3 Add primary coach orchestration entry lane
  • 1860f14 Add provider-backed recognition sidecar client
  • 2473665 Overlay imported training catalog packs and finite bundles
• the bounded permissive Phase 6R-A HactarCE/Hyperspeedcube puzzle-catalog contract widening packet is now landed in current code
• the bounded permissive Phase 6R-K HactarCE/Hyperspeedcube notation and replay-log serialization packet is now landed in current code
• the bounded permissive Phase 6R-L HactarCE/Hyperspeedcube replay verification packet is now landed in current code
• the bounded permissive Phase 6R-M HactarCE/Hyperspeedcube stats-shape and solve-record packet is now landed in current code
• HactarCE/Hyperspeedcube remains partially incorporated
• the bounded permissive Phase 6R-B kkoomen/qbr classic-cube recognition calibration and ordered face-observation packet is now landed in current code
• the bounded permissive Phase 6R-O kkoomen/qbr webcam UI shell packet is now landed in current code
• the bounded permissive Phase 6R-AK kkoomen/qbr locale-aware solve-guidance routing overlay packet is now landed in current code
• the bounded permissive Phase 6R-AN kkoomen/qbr multilingual solve-shell presentation posture packet is now landed in current code
• the bounded permissive Phase 6R-AS kkoomen/qbr bundled-font review boundary packet is now landed in current code
• the bounded permissive Phase 6R-AO cjpais/Handy global hotkey, mute, and device-selection shell packet is now landed in current code
• the bounded permissive Phase 6R-AU cjpais/Handy local model catalog, integrity, and unload policy shell packet is now landed in current code
• kkoomen/qbr remains partially incorporated
• the bounded permissive Phase 6R-C vivaansinghvi07/rubix-cube-solver committed-face reconstruction and face-vote replacement packet is now landed in current code
• the bounded permissive Phase 6R-P vivaansinghvi07/rubix-cube-solver browser/webcam shell packet is now landed in current code
• the bounded permissive Phase 6R-Q vivaansinghvi07/rubix-cube-solver solve explanation/recommendation shell packet is now landed in current code
• the bounded permissive Phase 6R-AT vivaansinghvi07/rubix-cube-solver bundled twistysim.min.js asset review boundary packet is now landed in current code
• vivaansinghvi07/rubix-cube-solver remains partially incorporated
• the generic source-backed Phase 6R-AV yakupbilen/drl-rubiks-cube learned-search and ADI experimentation control pass is now consumed
• the bounded first-party Phase 6R-AV learned heuristic search and ADI experimentation packet grounded in yakupbilen/drl-rubiks-cube is now landed in current code
• the bounded first-party Phase 6R-AW learned-search sequence-policy and search-budget refinement packet grounded in the same yakupbilen benchmark slice is now landed in current code
• the bounded first-party Phase 6R-AX learned-search node-identity and state-expansion boundary packet grounded in the same yakupbilen benchmark slice is now landed in current code
• the bounded first-party Phase 6R-AY learned-search frontier-scoring and solution-unwind boundary packet grounded in the same yakupbilen benchmark slice is now landed in current code
• the bounded first-party Phase 6R-AZ learned-search value-network shape and generator-sync boundary packet grounded in the same yakupbilen benchmark slice is now landed in current code
• the bounded first-party Phase I-A scenic virtual training environment foundations packet is now landed in current code
• the bounded first-party Phase I-B immersion and focus-presence controls packet is now landed in current code
• the bounded first-party Phase I-C spatial coaching and tutorial staging packet is now landed in current code
• the bounded first-party Phase I-D reactive session-state environment cues packet is now landed in current code
• the bounded first-party Phase I-E comfort, accessibility, and performance hardening packet is now landed in current code
• the bounded first-party Phase J-A replay integrity and validation benchmark foundations packet is now landed in current code
• the bounded first-party Phase J-B regression snapshots and cross-run benchmark deltas packet is now landed in current code
• the bounded first-party Phase J-C validation evidence exports and benchmark fixture packets is now landed in current code
• the bounded first-party Phase J-D validation run summaries and operator review packets is now landed in current code
• the bounded first-party Phase J-E validation triage queues and manual sign-off notes is now landed in current code
• the bounded first-party Phase J-F validation exception waivers and bounded handoff closures is now landed in current code
• the bounded first-party Phase J-G validation carry-forward ledgers and reviewer continuity digests is now landed in current code
• the bounded first-party Phase J-H validation disposition snapshots and bounded reopen notes is now landed in current code
• the bounded first-party Phase J-I validation deferred follow-up bundles and bounded revisit cues is now landed in current code
• the bounded first-party Phase J-J validation revisit completion receipts and bounded pending-state clearances is now landed in current code
• the bounded first-party Phase J-K validation dormant-state ledgers and bounded resurfacing cues is now landed in current code
• the bounded first-party Phase J-L validation return-readiness packets and bounded wake-state confirmations is now landed in current code
• the bounded first-party Phase J-M validation resumed-state checkpoints and bounded continuation attestations is now landed in current code
• the bounded first-party Phase J-N validation stable-state ledgers and bounded continuation-state digests is now landed in current code
• the bounded first-party Phase J-O validation settled-state packets and bounded ongoing-state confirmations is now landed in current code
• the bounded first-party Phase J-P validation persistent-state ledgers and bounded ongoing-state acknowledgements is now landed in current code
• the bounded first-party Phase J-Q validation durable-state packets and bounded ongoing-state attestations is now landed in current code
• the bounded first-party Phase J-R validation enduring-state ledgers and bounded ongoing-state certifications is now landed in current code
• the bounded first-party Phase J-S validation sustained-state packets and bounded ongoing-state assurances is now landed in current code
• the bounded first-party Phase J-T validation anchored-state ledgers and bounded ongoing-state affirmations is now landed in current code
• the bounded first-party Phase J-U validation grounded-state packets and bounded ongoing-state endorsements is now landed in current code
• the bounded first-party Phase J-V validation rooted-state ledgers and bounded ongoing-state ratifications is now landed in current code
• the bounded first-party Phase J-W validation embedded-state packets and bounded ongoing-state reconciliations is now landed in current code
• the bounded first-party Phase J-X validation nested-state ledgers and bounded ongoing-state harmonizations is now landed in current code
• the bounded first-party Phase J-Y validation layered-state packets and bounded ongoing-state alignments is now landed in current code
• the bounded first-party Phase J-Z validation stacked-state ledgers and bounded ongoing-state convergences is now landed in current code
• the bounded first-party Phase J-AA validation composite-state packets and bounded ongoing-state syntheses is now landed in current code
• the bounded first-party Phase J-AB validation aggregated-state ledgers and bounded ongoing-state consolidations is now landed in current code
• the bounded first-party Phase J-AC validation integrated-state packets and bounded ongoing-state unifications is now landed in current code
• the bounded first-party Phase J-AD validation fused-state ledgers and bounded ongoing-state coherences is now landed in current code
• the bounded first-party Phase J-AE validation merged-state packets and bounded ongoing-state concordances is now landed in current code
• the bounded first-party Phase J-AF validation blended-state ledgers and bounded ongoing-state correspondences is now landed in current code
• the bounded first-party Phase J-AG validation interlaced-state packets and bounded ongoing-state affinities is now landed in current code
• the bounded first-party Phase J-AH validation woven-state ledgers and bounded ongoing-state resonances is now landed in current code
• the bounded first-party Phase J-AI validation knotted-state packets and bounded ongoing-state harmonics is now landed in current code
• the bounded first-party Phase J-AJ validation braided-state ledgers and bounded ongoing-state cadences is now landed in current code
• the bounded first-party Phase J-AK validation looped-state packets and bounded ongoing-state refrains is now landed in current code
• the bounded first-party Phase J-AL validation spiraled-state ledgers and bounded ongoing-state choruses is now landed in current code
• the bounded first-party Phase J-AM validation coiled-state packets and bounded ongoing-state reprises is now landed in current code
• the bounded first-party Phase J-AN validation helixed-state ledgers and bounded ongoing-state echoes is now landed in current code
• the bounded first-party Phase J-AO validation twisted-state packets and bounded ongoing-state reflections is now landed in current code
• the bounded first-party Phase J-AP validation wound-state ledgers and bounded ongoing-state reverberations is now landed in current code
• the bounded first-party Phase J-AQ validation folded-state packets and bounded ongoing-state aftertones is now landed in current code
• the bounded first-party Phase J-AR validation creased-state ledgers and bounded ongoing-state residues is now landed in current code
• the bounded first-party Phase J-AS validation pleated-state packets and bounded ongoing-state remnants is now landed in current code
• the bounded first-party Phase J-AT validation crimped-state ledgers and bounded ongoing-state imprints is now landed in current code
• the bounded first-party Phase J-AU validation corrugated-state packets and bounded ongoing-state traces is now landed in current code
• the bounded first-party Phase J-AV validation ribbed-state ledgers and bounded ongoing-state signatures is now landed in current code
• the bounded first-party Phase J-AW validation fluted-state packets and bounded ongoing-state marks is now landed in current code
• the bounded first-party Phase J-AX validation grooved-state ledgers and bounded ongoing-state seals is now landed in current code
• the bounded first-party Phase J-AY validation ridged-state packets and bounded ongoing-state stamps is now landed in current code
• the bounded first-party Phase J-AZ validation terraced-state ledgers and bounded ongoing-state impressions is now landed in current code
• the bounded first-party Phase J-BA validation buttressed-state packets and bounded ongoing-state etchings is now landed in current code
• the bounded first-party Phase J-BB validation bastioned-state ledgers and bounded ongoing-state engravings is now landed in current code
• the bounded first-party Phase J-BC validation fortified-state packets and bounded ongoing-state carvings is now landed in current code
• the bounded first-party Phase J-BD validation bulwarked-state ledgers and bounded ongoing-state inscriptions is now landed in current code
• the bounded first-party Phase J-BE validation rampart-state packets and bounded ongoing-state markings is now landed in current code
• the bounded first-party Phase J-BF validation citadel-state ledgers and bounded ongoing-state tracings is now landed in current code
• the bounded first-party Phase J-BG validation keep-state packets and bounded ongoing-state notations is now landed in current code
• the bounded first-party Phase J-BH validation stronghold-state ledgers and bounded ongoing-state annotations is now landed in current code
• the bounded first-party Phase J-BI validation watchtower-state packets and bounded ongoing-state glosses is now landed in current code
• the bounded first-party Phase J-BJ validation battlement-state ledgers and bounded ongoing-state captions is now landed in current code
• the bounded first-party Phase J-BK validation parapet-state packets and bounded ongoing-state legends is now landed in current code
• the bounded first-party Phase J-BL validation merlon-state ledgers and bounded ongoing-state callouts is now landed in current code
• the bounded first-party Phase J-BM validation crenel-state packets and bounded ongoing-state marginalia is now landed in current code
• the bounded first-party Phase J-BN validation embrasure-state ledgers and bounded ongoing-state sidenotes is now landed in current code
• the bounded first-party Phase J-BO validation machicolation-state packets and bounded ongoing-state footnotes is now landed in current code
• the bounded first-party Phase J-BP validation bartizan-state ledgers and bounded ongoing-state endnotes is now landed in current code
• the bounded first-party Phase J-BQ validation turret-state packets and bounded ongoing-state addenda is now landed in current code
• the bounded first-party Phase J-BR validation barbican-state ledgers and bounded ongoing-state appendices is now landed in current code
• the bounded first-party Phase J-BS validation gatehouse-state packets and bounded ongoing-state codicils is now landed in current code
• the bounded first-party Phase J-BT validation portcullis-state ledgers and bounded ongoing-state postscripts is now landed in current code
• the bounded first-party Phase J-BU validation drawbridge-state packets and bounded ongoing-state afterwords is now landed in current code
• the bounded first-party Phase J-BV validation moat-state ledgers and bounded ongoing-state epilogues is now landed in current code
• the bounded first-party Phase J-BW validation causeway-state packets and bounded ongoing-state codas is now landed in current code
• the bounded first-party Phase J-BX validation viaduct-state ledgers and bounded ongoing-state encores is now landed in current code
• the bounded first-party Phase J-BY validation aqueduct-state packets and bounded ongoing-state finales is now landed in current code
• the bounded first-party Phase J-BZ validation trestle-state ledgers and bounded ongoing-state curtain-calls is now landed in current code
• the bounded first-party Phase J-CA validation span-state packets and bounded ongoing-state bows is now landed in current code
• the bounded first-party Phase J-CB validation arch-state ledgers and bounded ongoing-state ovations is now landed in current code
• the bounded first-party Phase J-CC validation vault-state packets and bounded ongoing-state applause is now landed in current code
• the bounded first-party Phase J-CD validation keystone-state ledgers and bounded ongoing-state acclamations is now landed in current code
• the bounded first-party Phase J-CE validation abutment-state packets and bounded ongoing-state commendations is now landed in current code
• the bounded first-party Phase J-CF validation pier-state ledgers and bounded ongoing-state tributes is now landed in current code
• the bounded first-party Phase J-CG validation footing-state packets and bounded ongoing-state homages is now landed in current code
• the bounded first-party Phase J-CH validation pilaster-state ledgers and bounded ongoing-state salutes is now landed in current code
• the bounded first-party Phase J-CI validation column-state packets and bounded ongoing-state accolades is now landed in current code
• the bounded first-party Phase J-CJ validation capital-state ledgers and bounded ongoing-state plaudits is now landed in current code
• the bounded first-party Phase J-CK validation frieze-state packets and bounded ongoing-state laurels is now landed in current code
• the bounded first-party Phase J-CL validation cornice-state ledgers and bounded ongoing-state honors is now landed in current code
• the bounded first-party Phase J-CM validation pediment-state packets and bounded ongoing-state distinctions is now landed in current code
• the bounded first-party Phase J-CN validation entablature-state ledgers and bounded ongoing-state recognitions is now landed in current code
• the bounded first-party Phase J-CO validation architrave-state packets and bounded ongoing-state appreciations is now landed in current code
• the bounded first-party Phase J-CP validation metope-state ledgers and bounded ongoing-state admirations is now landed in current code
• the bounded first-party Phase J-CQ validation triglyph-state packets and bounded ongoing-state esteem is now landed in current code
• the bounded first-party Phase J-CR validation regula-state ledgers and bounded ongoing-state regard is now landed in current code
• the bounded first-party Phase J-CS validation guttae-state packets and bounded ongoing-state respect is now landed in current code
• the bounded first-party Phase J-CT validation mutule-state ledgers and bounded ongoing-state deference is now landed in current code
• the bounded first-party Phase J-CU validation taenia-state packets and bounded ongoing-state reverence is now landed in current code
• the bounded first-party Phase J-CV validation cymatium-state ledgers and bounded ongoing-state veneration is now landed in current code
• the bounded first-party Phase J-CW validation sima-state packets and bounded ongoing-state devotion is now landed in current code
• the bounded first-party Phase J-CX validation corona-state ledgers and bounded ongoing-state adoration is now landed in current code
• the bounded first-party Phase J-CY validation soffit-state packets and bounded ongoing-state praise is now landed in current code
• the bounded first-party Phase J-CZ validation fascia-state ledgers and bounded ongoing-state exaltation is now landed in current code
• the bounded first-party Phase J-DA validation fillet-state packets and bounded ongoing-state glorification is now landed in current code
• the bounded first-party Phase J-DB validation bead-state ledgers and bounded ongoing-state celebration is now landed in current code
• the bounded first-party Phase J-DC validation ovolo-state packets and bounded ongoing-state jubilation is now landed in current code
• the bounded first-party Phase J-DD validation cavetto-state ledgers and bounded ongoing-state rejoicing is now landed in current code
• the bounded first-party Phase J-DE validation torus-state packets and bounded ongoing-state exultation is now landed in current code
• the bounded first-party Phase J-DF validation scotia-state ledgers and bounded ongoing-state elation is now landed in current code
• the bounded first-party Phase J-DG validation cyma-state packets and bounded ongoing-state delight is now landed in current code
• the bounded first-party Phase J-DH validation astragal-state ledgers and bounded ongoing-state gladness is now landed in current code
• the bounded first-party Phase J-DI validation trochilus-state packets and bounded ongoing-state cheer is now landed in current code
• the bounded first-party Phase J-DJ validation annulet-state ledgers and bounded ongoing-state joy is now landed in current code
• the bounded first-party Phase J-DK validation listel-state packets and bounded ongoing-state merriment is now landed in current code
• the bounded first-party Phase J-DL validation cincture-state ledgers and bounded ongoing-state gaiety is now landed in current code
• the bounded first-party Phase J-DM validation girdle-state packets and bounded ongoing-state revelry is now landed in current code
• the bounded first-party Phase J-DN validation collarino-state ledgers and bounded ongoing-state festivity is now landed in current code
• the bounded first-party Phase J-DO validation apophyge-state packets and bounded ongoing-state conviviality is now landed in current code
• the bounded first-party Phase J-DP validation doucine-state ledgers and bounded ongoing-state sociability is now landed in current code
• the bounded first-party Phase J-DQ validation cyma-recta-state packets and bounded ongoing-state fellowship is now landed in current code
• the bounded first-party Phase J-DR validation cyma-reversa-state ledgers and bounded ongoing-state camaraderie is now landed in current code
• the bounded first-party Phase J-DS validation echinus-state packets and bounded ongoing-state companionship is now landed in current code
• the bounded first-party Phase J-DT validation abacus-state ledgers and bounded ongoing-state fraternity is now landed in current code
• the bounded first-party Phase J-DU validation necking-state packets and bounded ongoing-state solidarity is now landed in current code
• the bounded first-party Phase J-DV validation hypotrachelion-state ledgers and bounded ongoing-state alliance is now landed in current code
• the bounded first-party Phase J-DW validation gorgerin-state packets and bounded ongoing-state accord is now landed in current code
• the bounded first-party Phase J-DX validation bolster-state ledgers and bounded ongoing-state concord is now landed in current code
• the bounded first-party Phase J-DY validation taper-state packets and bounded ongoing-state harmony is now landed in current code
• the bounded first-party Phase J-DZ validation shaft-state ledgers and bounded ongoing-state unity is now landed in current code
• the bounded first-party Phase J-EA validation base-state packets and bounded ongoing-state union is now landed in current code
• the bounded first-party Phase J-EB validation plinth-state ledgers and bounded ongoing-state coalition is now landed in current code
• the bounded first-party Phase J-EC validation pedestal-state packets and bounded ongoing-state partnership is now landed in current code
• the bounded first-party Phase J-ED validation stylobate-state ledgers and bounded ongoing-state consortium is now landed in current code
• the bounded first-party Phase J-EE validation stereobate-state packets and bounded ongoing-state federation is now landed in current code
• the bounded first-party Phase J-EF validation podium-state ledgers and bounded ongoing-state confederation is now landed in current code
• the bounded first-party Phase J-EG validation dais-state packets and bounded ongoing-state league is now landed in current code
• the bounded first-party Phase J-EH validation rostrum-state ledgers and bounded ongoing-state assembly is now landed in current code
• the bounded first-party Phase J-EI validation tribune-state packets and bounded ongoing-state forum is now landed in current code
• the bounded first-party Phase J-EJ validation lectern-state ledgers and bounded ongoing-state council is now landed in current code
• the bounded first-party Phase J-EK validation pulpit-state packets and bounded ongoing-state caucus is now landed in current code
• the bounded first-party Phase J-EL validation ambo-state ledgers and bounded ongoing-state quorum is now landed in current code
• the bounded first-party Phase J-EM validation minbar-state packets and bounded ongoing-state conclave is now landed in current code
• the bounded first-party Phase J-EN validation cathedra-state ledgers and bounded ongoing-state synod is now landed in current code
• the bounded first-party Phase J-EO validation bema-state packets and bounded ongoing-state convocation is now landed in current code
• the bounded first-party Phase J-EP validation sedilia-state ledgers and bounded ongoing-state chapter is now landed in current code
• the bounded first-party Phase J-EQ validation choir-state packets and bounded ongoing-state vestry is now landed in current code
• the bounded first-party Phase J-ER validation stall-state ledgers and bounded ongoing-state consistory is now landed in current code
• the bounded first-party Phase J-ES validation pew-state packets and bounded ongoing-state presbytery is now landed in current code
• the bounded first-party Phase J-ET validation nave-state ledgers and bounded ongoing-state transept is now landed in current code
• the bounded first-party Phase J-EU validation aisle-state packets and bounded ongoing-state chancel is now landed in current code
• the bounded first-party Phase J-EV validation sanctuary-state ledgers and bounded ongoing-state apse is now landed in current code
• the bounded first-party Phase J-EW validation altar-state packets and bounded ongoing-state reredos is now landed in current code
• the bounded first-party Phase J-EX validation retable-state ledgers and bounded ongoing-state iconostasis is now landed in current code
• the bounded first-party Phase J-EY validation ciborium-state packets and bounded ongoing-state baldachin is now landed in current code
• the bounded first-party Phase J-EZ validation predella-state ledgers and bounded ongoing-state dossal is now landed in current code
• the bounded first-party Phase J-FA validation frontal-state packets and bounded ongoing-state antependium is now landed in current code
• the bounded first-party Phase J-FB validation superfrontal-state ledgers and bounded ongoing-state fair-linen is now landed in current code
• the bounded first-party Phase J-FC validation corporal-state packets and bounded ongoing-state pall is now landed in current code
• the bounded first-party Phase J-FD validation purificator-state ledgers and bounded ongoing-state chalice-veil is now landed in current code
• the bounded first-party Phase J-FE validation paten-state packets and bounded ongoing-state burse is now landed in current code
• the bounded first-party Phase J-FF validation pyx-state ledgers and bounded ongoing-state monstrance is now landed in current code
• the bounded first-party Phase J-FG validation cruet-state packets and bounded ongoing-state lavabo is now landed in current code
• the bounded first-party Phase J-FH validation thurible-state ledgers and bounded ongoing-state navicula is now landed in current code
• the bounded first-party Phase J-FI validation aspergillum-state packets and bounded ongoing-state aspersorium is now landed in current code
• the bounded first-party Phase J-FJ validation stoup-state ledgers and bounded ongoing-state font is now landed in current code
• the bounded first-party Phase J-FK validation piscina-state packets and bounded ongoing-state credence is now landed in current code
• the bounded first-party Phase J-FL validation aumbry-state ledgers and bounded ongoing-state tabernacle is now landed in current code
• the bounded first-party Phase J-FM validation sacrarium-state packets and bounded ongoing-state conopeum is now landed in current code
• the bounded first-party Phase J-FN validation lunette-state ledgers and bounded ongoing-state humeral-veil is now landed in current code
• the bounded first-party Phase J-FO validation custodia-state packets and bounded ongoing-state pyx-cloth is now landed in current code
• the bounded first-party Phase J-FP validation ostensorium-state ledgers and bounded ongoing-state velum is now landed in current code
• the bounded first-party Phase J-FQ validation lunula-state ledgers and bounded ongoing-state cope is now landed in current code
• the bounded first-party Phase J-FR validation amice-state ledgers and bounded ongoing-state stole is now landed in current code
• the bounded first-party Phase J-FS validation alb-state ledgers and bounded ongoing-state chasuble is now landed in current code
• the bounded first-party Phase J-FT validation dalmatic-state ledgers and bounded ongoing-state tunicle is now landed in current code
• the bounded first-party Phase J-FU validation maniple-state ledgers and bounded ongoing-state fanon is now landed in current code
• the bounded first-party Phase J-FV validation mitre-state ledgers and bounded ongoing-state crosier is now landed in current code
• the bounded first-party Phase J-FW validation pectoral-cross-state ledgers and bounded ongoing-state ring is now landed in current code
• the bounded first-party Phase J-FX validation zucchetto-state ledgers and bounded ongoing-state biretta is now landed in current code
• the bounded first-party Phase J-FY validation mozzetta-state ledgers and bounded ongoing-state rochet is now landed in current code
• the bounded first-party Phase J-FZ validation surplice-state ledgers and bounded ongoing-state tippet is now landed in current code
• the bounded first-party Phase J-GA validation chimere-state ledgers and bounded ongoing-state scarf is now landed in current code
• the bounded first-party Phase J-GB validation cassock-state ledgers and bounded ongoing-state rabat is now landed in current code
• the bounded first-party Phase J-GC validation camauro-state ledgers and bounded ongoing-state saturno is now landed in current code
• the bounded first-party Phase J-GD validation ferraiolo-state ledgers and bounded ongoing-state mantelletta is now landed in current code
• the bounded first-party Phase J-GE validation cappa-magna-state ledgers and bounded ongoing-state pellegrina is now landed in current code
• the bounded first-party Phase J-GF validation galero-state ledgers and bounded ongoing-state simar is now landed in current code
• the bounded first-party Phase J-GG validation tabarro-state ledgers and bounded ongoing-state gremiale is now landed in current code
• the bounded first-party Phase J-GH validation falda-state ledgers and bounded ongoing-state mantum is now landed in current code
• the bounded first-party Phase J-GI validation sakkos-state ledgers and bounded ongoing-state omophorion is now landed in current code
• the bounded first-party Phase J-GJ validation epigonation-state ledgers and bounded ongoing-state epimanikia is now landed in current code
• the bounded first-party Phase J-GK validation orarion-state ledgers and bounded ongoing-state epitrachelion is now landed in current code
• the bounded first-party Phase J-GL validation sticharion-state ledgers and bounded ongoing-state zonarion is now landed in current code
• the bounded first-party Phase J-GM validation phelonion-state ledgers and bounded ongoing-state riassa is now landed in current code
• the bounded first-party Phase J-GN validation klobuk-state ledgers and bounded ongoing-state mandyas is now landed in current code
• the bounded first-party Phase J-GO validation kamelavkion-state ledgers and bounded ongoing-state epanokamelavkion is now landed in current code
• the bounded first-party Phase J-GP validation koukoulion-state ledgers and bounded ongoing-state paramandyas is now landed in current code
• the bounded first-party Phase J-GQ validation analavos-state ledgers and bounded ongoing-state polystavrion is now landed in current code
• the bounded first-party Phase J-GR validation epanorion-state ledgers and bounded ongoing-state epirrhiptarion is now landed in current code
• the bounded first-party Phase J-GS validation engolpion-state ledgers and bounded ongoing-state panagia is now landed in current code
• the bounded first-party Phase J-GT validation dikerion-state ledgers and bounded ongoing-state trikerion is now landed in current code
• the bounded first-party Phase J-GU validation ripidion-state ledgers and bounded ongoing-state asteriskos is now landed in current code
• the bounded first-party Phase J-GV validation diskos-state ledgers and bounded ongoing-state kalymma is now landed in current code
• the bounded first-party Phase J-GW validation antimension-state ledgers and bounded ongoing-state eiliton is now landed in current code
• the bounded first-party Phase J-GX validation aer-state ledgers and bounded ongoing-state labis is now landed in current code
• the bounded first-party Phase J-GY validation diskarion-state ledgers and bounded ongoing-state zeon is now landed in current code
• the bounded first-party Phase J-GZ validation lonche-state ledgers and bounded ongoing-state lance is now landed in current code
• the bounded first-party Phase J-HA validation lavida-state ledgers and bounded ongoing-state sudarion is now landed in current code
• the bounded first-party Phase J-HB validation hexapterygon-state ledgers and bounded ongoing-state cherubikon is now landed in current code
• the bounded first-party Phase J-HC validation anaphora-state ledgers and bounded ongoing-state epiclesis is now landed in current code
• yakupbilen/drl-rubiks-cube remains benchmark-grounded; live recognition/reconstruction ownership stays with qbr and rubix-cube-solver, while correctness/performance oracle ownership stays with brownan and efrantar
• the bounded permissive Phase 6R-D roice3/MagicTile tiling topology and geometry-family packet is now landed in current code
• the bounded first-party Phase 7A MagicTile embedded-browser host-decision packet is now landed in current code
• the bounded first-party Phase 7B MagicTile browser state-bridge packet is now landed in current code
• roice3/MagicTile remains partially incorporated; broad non-Euclidean interaction, native spherical/hyperbolic renderer ownership before first-party behavior proof, WinForms / OpenTK host ownership, and generic runtime replacement stay deferred
• the bounded permissive Phase 6R-E ggml-org/whisper.cpp speech transcript session packet is now landed in current code
• ggml-org/whisper.cpp remains partially incorporated
• the provider-family backfill now keeps the top-level speech/provider contract explicitly first-party and provider-neutral
• the generic source-backed Phase 6R-F SYSTRAN/faster-whisper control pass is now consumed
• the bounded permissive Phase 6R-F SYSTRAN/faster-whisper transcription-service orchestration packet is now landed in current code
• the bounded permissive Phase 6R-AP SYSTRAN/faster-whisper batch-window and prompt/retrieval tuning packet is now landed in current code
• SYSTRAN/faster-whisper remains partially incorporated
• the generic source-backed Phase 6R-G rhasspy/piper control pass is now consumed
• the bounded permissive Phase 6R-G rhasspy/piper local narration sidecar packet is now landed in current code
• the bounded permissive Phase 6R-AQ rhasspy/piper downloadable voice-asset review boundary packet is now landed in current code
• rhasspy/piper remains partially incorporated
• the generic source-backed Phase 6R-H coqui-ai/TTS control pass is now consumed
• the bounded permissive Phase 6R-H coqui-ai/TTS advanced narration orchestration packet is now landed in current code
• the bounded permissive Phase 6R-AR coqui-ai/TTS downloadable voice/model review boundary packet is now landed in current code
• the bounded permissive Phase 6R-N HactarCE/Hyperspeedcube puzzle-definition DSL packet is now landed in current code
• HactarCE/Hyperspeedcube is now closed for the currently justified retained families
• the bounded permissive Phase 6R-P vivaansinghvi07/rubix-cube-solver browser/webcam shell packet is now landed in current code
• the bounded permissive Phase 6R-Q vivaansinghvi07/rubix-cube-solver solve explanation/recommendation packet is now landed in current code
• the generic source-backed Phase 6R-R shared classic-cube recognition multi-face correction/explanation control pass is now consumed
• the bounded permissive Phase 6R-R shared classic-cube recognition multi-face correction/explanation shell packet is now landed in current code
• the generic source-backed Phase 6R-S shared classic-cube correction-resolution closure control pass is now consumed
• the bounded permissive Phase 6R-S shared classic-cube correction-resolution closure packet is now landed in current code
• the generic source-backed Phase 6R-T roice3/MagicTile transform-aware macro remapping control pass is now consumed
• the bounded permissive Phase 6R-T roice3/MagicTile transform-aware macro remapping packet is now landed in current code
• the bounded first-party Phase 7A MagicTile embedded-browser host-decision packet is now landed in current code
• the bounded first-party Phase 7B MagicTile browser state-bridge packet is now landed in current code
• the generic source-backed Phase 6R-U ggml-org/whisper.cpp live microphone capture shell control pass is now consumed
• the bounded permissive Phase 6R-U ggml-org/whisper.cpp live microphone capture shell packet is now landed in current code
• the generic source-backed Phase 6R-V ggml-org/whisper.cpp device-permission and capture-route readiness shell control pass is now consumed
• the bounded permissive Phase 6R-V ggml-org/whisper.cpp device-permission and capture-route readiness shell packet is now landed in current code
• the generic source-backed Phase 6R-W ggml-org/whisper.cpp downloadable model and payload custody control pass is now consumed
• the bounded permissive Phase 6R-W ggml-org/whisper.cpp downloadable model and payload custody packet is now landed in current code
• the generic source-backed Phase 6R-X first-party provider-profile and BYOK custody control pass is now consumed
• the bounded first-party Phase 6R-X provider-profile and BYOK custody packet is now landed in current code
• the generic source-backed Phase 6R-Y first-party provider routing and policy control pass is now consumed
• the bounded first-party Phase 6R-Y provider routing and policy packet is now landed in current code
• the generic source-backed Phase 6R-Z first-party normalized usage/cost event-model control pass is now consumed
• the bounded first-party Phase 6R-Z normalized usage/cost event-model packet is now landed in current code
• the generic source-backed Phase 6R-AA first-party operator-facing provider usage/cost dashboard shell control pass is now consumed
• the bounded first-party Phase 6R-AA operator-facing provider usage/cost dashboard shell packet is now landed in current code
• the generic source-backed Phase 6R-AB first-party provider usage/cost history/export shell control pass is now consumed
• the bounded first-party Phase 6R-AB provider usage/cost history/export shell packet is now landed in current code
• the generic source-backed Phase 6R-AC first-party provider receipt review and posted-charge inspection control pass is now consumed
• the bounded first-party Phase 6R-AC provider receipt review and posted-charge inspection packet is now landed in current code
• the generic source-backed Phase 6R-AD first-party provider billing settlement and invoice reconciliation control pass is now consumed
• the bounded first-party Phase 6R-AD provider billing settlement and invoice reconciliation packet is now landed in current code
• the generic source-backed Phase 6R-AE first-party provider settlement exception and external-portal handoff control pass is now consumed
• the bounded first-party Phase 6R-AE provider settlement exception and external-portal handoff packet is now landed in current code
• the generic source-backed Phase 6R-AF first-party real device-permission workflow control pass is now consumed
• the bounded first-party Phase 6R-AF real device-permission workflow packet is now landed in current code
• the generic source-backed Phase 6R-AG first-party native capture-route ownership and workflow preparation/control pass is now consumed
• the bounded first-party Phase 6R-AG native capture-route ownership and workflow preparation/control packet is now landed in current code
• the current next bounded move is not another restrictive packet by default; if a new speech-adjacent first-party packet is justified, keep actual OS permission-grant execution, actual payment execution, provider-portal ownership, and actual payload shipping separately deferred
• use the repo-row README census, the portfolio standing refresh backfill, and the 2R-A ownership contract for the current queue after that correction

This file now also preserves the current truth that future models must not lose:

• current curated HyperTwist shallow-eval set: 75 repos
• currently verified live/implemented in checked UnrealHyperTwist surfaces: 35
• permissive live lanes: 22
• boundary-sensitive live lanes: 6
• restrictive live lanes: 6
• the dedicated current doctrine note for MPL-side non-GPL usage is:
  • HYPERTWIST_MPL_BOUNDARY_AND_NON_GPL_USAGE_DOCTRINE_2026-05-25.md
• the dedicated release-placement checklist for that route is:
  • HYPERTWIST_MPL_DISTRIBUTION_PLACEMENT_CHECKLIST_2026-05-25.md
  • that checklist governs both browser-delivered MPL code and any public commercial website, store, checkout, release, or download surface that sells or delivers a build containing those MPL lanes
  • that checklist now also separates the three cumulative HyperTwist delivery cases explicitly:
    • browser-delivered online use
    • public store, checkout, release, and download pages
    • bundled executable, installer, desktop package, or mobile package

The twenty-two permissive live lanes are:

• Aarav2709/KubeTimr
• HactarCE/Hyperspeedcube
• kkoomen/qbr
• vivaansinghvi07/rubix-cube-solver
• apache/echarts
• abunickabhi/5style-Trainer
• google/model-viewer
• Hypercubers/hypercubing.xyz
• mrdoob/three.js
• pmndrs/react-three-fiber
• pmndrs/xr
• tao-yu/Alg-Trainer
• Lykos/cube_trainer
• met4citizen/TalkingHead
• newyork-anthonyng/rubiks-cross-trainer
• roice3/MagicTile
• ggml-org/whisper.cpp
• SYSTRAN/faster-whisper
• rhasspy/piper
• coqui-ai/TTS
• roice3/Magic120Cell
• roice3/MagicCube5D

The six boundary-sensitive live lanes are:

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

2026-06-12 routing correction:

• preserve the already-landed first-party Phase 4R-F outputs
• do not treat remotion-dev/remotion as a default future boundary-sensitive widening lane even though older summaries grouped it here
• route future donor-backed widening from remotion-dev/remotion through restrictive custody and explicit clean-room/specification work, or replace it with a first-party Unreal-native export path

Those boundary-sensitive lanes should now be treated as:

• implementation-authorized without clean-room by default
• landed only through bounded dependency, subtree-boundary, allowlist, package-split, or adapter contracts
• still subject to their narrower license and provenance obligations

Key clarification for current live rows:

• cubing/cubing.js is a live boundary-sensitive lane through the accepted MPL-side adapter/dependency route, not a restrictive clean-room lane
• coqui-ai/TTS is a live bounded code-side lane for HyperTwist under MPL-2.0, but model and payload review remains separate; that row is not a blanket payload approval and not a clean-room requirement by default

The six restrictive live lanes are:

• onionhoney/roux-trainers
• cubing/alg.js
• cubing/twisty.js
• HactarCE/2x2x2x2-Scrambler
• kash/cubedesk
• poliva/cubedex

Current restrictive-routing clarification:

• remotion-dev/remotion now shares the restrictive-custody future-widening posture even though the older summary above still preserves its historical Phase 4R-F landing position

Those restrictive lanes should now be treated as:

• the five historically restrictive implementation lanes remain properly clean-roomed and already landed/live
• poliva/cubedex is a restrictive-custody correction: preserve the existing first-party outputs already landed in HyperTwist, treat the row as restrictive comparison context only, and do not widen from the donor mirror without restored source-backed license evidence or a later narrower clean-room justification

Interpretation rule:

• repo-row legal posture does not equal implementation truth
• integrate, repurpose, selected, donor bench, locked strategic donor, and similar labels must not be casually translated into already implemented

Reset rule:

• preserve the thirty-four landed/live lanes
• do not treat the remaining non-live rows as already absorbed
• route all non-live rows only through the closed Phase 1R retained-set contract and the relevant 0R-* packet

Current Phase 0R packet status:

• 0R-A is closed
• 0R-B is closed
• 0R-C is closed
• 0R-D is closed
• 0R-E is closed

Current 0R-E clarification:

• the v6.3 CSV live-state label not_live_reference_or_discard_candidate is intentionally too coarse to distinguish retained benchmark rows from discarded rows
• use 0R-E packet authority, not the CSV alone, for the final retained-versus-discarded split
• retained 0R-E benchmark, oracle, or clean-room-later rows are:
  • cs0x7f/cstimer
  • brownan/Rubiks-Cube-Solver
  • efrantar/rob-twophase
  • ShellPuppy/RCube
  • vwcwong/CubeSim
  • AviKaufman/Rubix-cube-trainer
  • alinen/cube
  • ambisinister/blindsolve
  • yakupbilen/drl-rubiks-cube
• discarded active-set 0R-E rows are:
  • aMonteSl/CodeXR
  • MathewKJ2048/Rubiks-cube-simulator
  • brianpeiris/RiftSketch
• non-live rows already packet-evaluated: 65
• non-live rows still awaiting packet evaluation: 0

Current practical interpretation:

• Phase 0R is now fully closed
• Phase 1R is now fully closed
• Phase 2R-A is now fully closed for the five core retained permissive rows
• Phase 2R-B is now fully closed for the primary retained permissive support-plane rows in scope
• Phase 2R-C is now fully closed for the final residual 0R-B permissive rows
• Phase 2R is now fully closed for the retained permissive set
• benchmark, reference, clean-room-later, and discard posture for the last twelve rows now lives in docs/HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md
• retained-set routing now lives in docs/HYPERTWIST_PHASE_1R_RETAINED_SET_CONTRACT_AND_HANDOFF_2026-05-13.md
• core ownership and acceptance packetization now lives in docs/HYPERTWIST_PHASE_2R_PACKET_2R_A_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md
• support-plane ownership and acceptance packetization now lives in docs/HYPERTWIST_PHASE_2R_PACKET_2R_B_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md
• residual 0R-B adjunct and alternative-lane packetization now lives in docs/HYPERTWIST_PHASE_2R_PACKET_2R_C_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md
• the landed Aarav2709/KubeTimr widening packet now lives in docs/HYPERTWIST_PHASE_3R_PACKET_3R_A_KUBETIMR_IMPLEMENTATION_2026-05-13.md
• the landed Hypercubers/hypercubing.xyz widening packet now lives in docs/HYPERTWIST_PHASE_3R_PACKET_3R_B_HYPERCUBING_XYZ_IMPLEMENTATION_2026-05-13.md
• the landed apache/echarts widening packet now lives in docs/HYPERTWIST_PHASE_3R_PACKET_3R_C_ECHARTS_IMPLEMENTATION_2026-05-13.md
• the landed google/model-viewer widening packet now lives in docs/HYPERTWIST_PHASE_3R_PACKET_3R_D_MODEL_VIEWER_IMPLEMENTATION_2026-05-13.md
• the landed met4citizen/TalkingHead widening packet now lives in docs/HYPERTWIST_PHASE_3R_PACKET_3R_E_TALKINGHEAD_IMPLEMENTATION_2026-05-13.md
• the landed mrdoob/three.js, pmndrs/react-three-fiber, and pmndrs/xr widening packet now lives in docs/HYPERTWIST_PHASE_3R_PACKET_3R_F_BROWSER_SPATIAL_SUPPORT_IMPLEMENTATION_2026-05-13.md
• the landed cubing/cubing.js boundary-sensitive widening packet now lives in docs/HYPERTWIST_PHASE_4R_PACKET_4R_A_CUBING_JS_ADAPTER_IMPLEMENTATION_2026-05-13.md
• the landed cutelyaware/magiccube4d boundary-sensitive widening packet now lives in docs/HYPERTWIST_PHASE_4R_PACKET_4R_B_MAGICCUBE4D_ADAPTER_IMPLEMENTATION_2026-05-13.md
• the landed google/model-viewer/packages/shared-assets boundary-sensitive widening packet now lives in docs/HYPERTWIST_PHASE_4R_PACKET_4R_C_SHARED_ASSETS_ALLOWLIST_IMPLEMENTATION_2026-05-13.md
• the landed PostHog/posthog boundary-sensitive widening packet now lives in docs/HYPERTWIST_PHASE_4R_PACKET_4R_D_POSTHOG_CONTROL_PLANE_IMPLEMENTATION_2026-05-13.md
• the landed screenpipe/screenpipe boundary-sensitive widening packet now lives in docs/HYPERTWIST_PHASE_4R_PACKET_4R_E_SCREENPIPE_CAPTURE_HISTORY_IMPLEMENTATION_2026-05-13.md
• the landed remotion-dev/remotion boundary-sensitive widening packet now lives in docs/HYPERTWIST_PHASE_4R_PACKET_4R_F_REMOTION_MEDIA_EXPORT_IMPLEMENTATION_2026-05-13.md
• the bounded first-party Phase 6R-AG native capture-route ownership and workflow preparation/control packet is now landed in current code

Companion docs:

• docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md
• docs/HT_REPO_INCORPORATION_AUDIT_2026-05-11.md
• docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md
• docs/HYPERTWIST_PHASE_1R_RETAINED_SET_CONTRACT_AND_HANDOFF_2026-05-13.md
• docs/HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md
• docs/HYPERTWIST_PHASE_2R_PACKET_2R_A_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md
• docs/HYPERTWIST_PHASE_2R_PACKET_2R_B_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md
• docs/HYPERTWIST_PHASE_2R_PACKET_2R_C_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md
• docs/HYPERTWIST_PHASE_3R_PACKET_3R_A_KUBETIMR_IMPLEMENTATION_2026-05-13.md
• docs/HYPERTWIST_PHASE_3R_PACKET_3R_B_HYPERCUBING_XYZ_IMPLEMENTATION_2026-05-13.md
• docs/HYPERTWIST_PHASE_3R_PACKET_3R_F_BROWSER_SPATIAL_SUPPORT_IMPLEMENTATION_2026-05-13.md
• docs/arch/HYPERTWIST_PHASE6R_A_HYPERSPEEDCUBE_PUZZLE_CATALOG_IMPLEMENTATION_PACKET_2026-05-20.md
• docs/arch/HYPERTWIST_PHASE6R_D_MAGICTILE_TILING_TOPOLOGY_IMPLEMENTATION_PACKET_2026-05-21.md
• docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md

Landed live-lane legal records

abunickabhi/5style-Trainer

Decision date:

• 2026-05-13

Current licensing judgment:

• MIT
• preserve the checked local license text exactly as present
• the checked local LICENSE notice names Tao Yu
• treat the derivative Tao-trainer lineage as a tracked provenance fact, not as noise to erase

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\abunickabhi\5style-Trainer\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\abunickabhi\5style-Trainer\README.md
• C:\HyperTwist\docs\HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md
• C:\HyperTwist\docs\HYPERTWIST_CROSS_PLANNING_AND_5STYLE_MICRO_DRILL_HIERARCHY_RECONCILIATION_2026-05-27.md

Practical obligations:

• preserve the MIT text in third-party notices or equivalent release/legal materials
• preserve the checked copyright notice to Tao Yu
• do not restate this lane as a plain standalone authorless MIT transplant

Approved working posture:

• preserve as the landed first-party permissive advanced 5-style / BLD micro-drill lane
• keep current first-party training/coaching code as the live session/review-plan/follow-up orchestration owner above this row
• do not flatten away the checked Tao-lineage provenance or widen this row into the broader trainer-foundation or persistence-heavy coaching owner
• widen only through ordinary owned enhancement work
• keep the lineage note visible in future legal or provenance summaries

tao-yu/Alg-Trainer

Decision date:

• 2026-05-13

Current licensing judgment:

• MIT

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\tao-yu\Alg-Trainer\LICENSE
• C:\HyperTwist\docs\HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md
• C:\HyperTwist\docs\HYPERTWIST_TRAINER_FOUNDATION_AND_PERSISTED_COACHING_HIERARCHY_RECONCILIATION_2026-05-27.md

Practical obligations:

• preserve the MIT text in third-party notices or equivalent release/legal materials
• preserve the checked copyright notice to Tao Yu

Approved working posture:

• preserve as the landed first-party permissive algorithm-training foundation lane
• keep current first-party training/coaching code as the live session/review-plan/follow-up orchestration owner above this row
• widen only through ordinary owned enhancement work

Aarav2709/KubeTimr

Decision date:

• 2026-05-13

Current licensing judgment:

• MIT
• preserve the checked local license text exactly as present
• the checked local license notice currently uses Copyright (c) 2024 KubeTimr

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\Aarav2709\KubeTimr\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\Aarav2709\KubeTimr\README.md
• C:\HyperTwist\docs\HYPERTWIST_PHASE_3R_PACKET_3R_A_KUBETIMR_IMPLEMENTATION_2026-05-13.md
• C:\HyperTwist\docs\HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md

Practical obligations:

• preserve the MIT text in third-party notices or equivalent release/legal materials
• preserve the checked copyright notice exactly as present

Approved working posture:

• preserve as a landed first-party permissive timer subsystem lane
• widen only through ordinary owned enhancement work
• treat future work as preserve-and-enhance work, not as unresolved donor-candidate work

Hypercubers/hypercubing.xyz

Decision date:

• 2026-05-13

Current licensing judgment:

• MIT
• preserve the checked local license text exactly as present
• the checked local license notice currently uses Copyright (c) 2023 Hypercubers

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\Hypercubers\hypercubing.xyz\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\Hypercubers\hypercubing.xyz\docs\progression.md
• C:\Workspaces\HyperTwist\mirrors\permissive\Hypercubers\hypercubing.xyz\docs\notation.md
• C:\Workspaces\HyperTwist\mirrors\permissive\Hypercubers\hypercubing.xyz\docs\software\index.md
• C:\Workspaces\HyperTwist\mirrors\permissive\Hypercubers\hypercubing.xyz\hooks\feature_matrix.py
• C:\Workspaces\HyperTwist\mirrors\permissive\Hypercubers\hypercubing.xyz\leaderboards\generate_leaderboards.py
• C:\HyperTwist\docs\HYPERTWIST_PHASE_3R_PACKET_3R_B_HYPERCUBING_XYZ_IMPLEMENTATION_2026-05-13.md
• C:\HyperTwist\docs\HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md

Practical obligations:

• preserve the MIT text in third-party notices or equivalent release/legal materials
• preserve the checked copyright notice exactly as present
• preserve the repo identity in provenance summaries when referencing the landed knowledge, notation, progression, software-comparison, or leaderboard-contract lane

Approved working posture:

• preserve as a landed first-party permissive hypercubing knowledge and community-reference lane
• widen only through ordinary owned enhancement work
• treat future work as preserve-and-enhance work, not as unresolved donor-candidate work
• do not let the repo's static-site shell or page prose override first-party product architecture ownership

Lykos/cube_trainer

Decision date:

• 2026-05-13

Current licensing judgment:

• MIT

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\Lykos\cube_trainer\LICENSE
• C:\HyperTwist\docs\HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md
• C:\HyperTwist\docs\HYPERTWIST_TRAINER_FOUNDATION_AND_PERSISTED_COACHING_HIERARCHY_RECONCILIATION_2026-05-27.md

Practical obligations:

• preserve the MIT text in third-party notices or equivalent release/legal materials
• preserve the checked copyright notice to Bernhard F. Brodowsky

Approved working posture:

• preserve as the landed first-party permissive persisted-coaching and weighted-sampling lane
• keep current first-party training/coaching code as the live session/review-plan/follow-up orchestration owner above this row
• widen only through ordinary owned enhancement work

poliva/cubedex

Decision date:

• 2026-05-13
• restrictive-custody correction on 2026-05-27

Current licensing judgment:

• no explicit license is visible in the checked local mirror
• the checked local mirror currently lacks a standalone LICENSE, COPYING, or NOTICE file
• the checked local package.json currently does not declare a license field
• treat the row as restrictive custody until restored source-backed license evidence proves otherwise
• preserve the already-landed first-party HyperTwist outputs, but do not treat the donor mirror as a normal permissive widening surface

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\poliva\cubedex\package.json
• C:\HyperTwist\docs\HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md
• C:\HyperTwist\docs\HYPERTWIST_SMARTCUBE_PRACTICE_REVIEW_AND_SRS_HIERARCHY_RECONCILIATION_2026-05-27.md
• current HyperTwist canonical row state and retained-set docs

Practical obligations:

• keep the mirror in restrictive custody
• keep the no-license posture explicitly recorded in legal and provenance tracking
• if future source-backed evidence restores a real upstream license basis, reopen this row selectively instead of silently flattening the correction
• until then, do not treat this repo as a permissive donor and do not allow Model B to read the mirror

Approved working posture:

• preserve the existing first-party outputs already landed in HyperTwist
• keep the current first-party training, review-plan, timer, and smart-device owners as the practical live family for this slice
• treat this row as restrictive comparison context only, not as a default clean-room implementation queue row
• block donor-backed widening from this mirror by default
• allow future widening only through independently owned first-party work, restored upstream license evidence, or a later clean-room route after a narrower first-party gap is actually proven

newyork-anthonyng/rubiks-cross-trainer

Decision date:

• 2026-05-13

Current licensing judgment:

• MIT

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\newyork-anthonyng\rubiks-cross-trainer\LICENSE
• C:\HyperTwist\docs\HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md
• C:\HyperTwist\docs\HYPERTWIST_CROSS_PLANNING_AND_5STYLE_MICRO_DRILL_HIERARCHY_RECONCILIATION_2026-05-27.md

Practical obligations:

• preserve the MIT text in third-party notices or equivalent release/legal materials
• preserve the checked copyright notice to Anthony Ng

Approved working posture:

• preserve as the landed first-party permissive CFOP cross-planning micro-drill lane
• keep current first-party training/coaching code as the live session/review-plan/follow-up orchestration owner above this row
• do not widen this row into broad algorithm-corpus ownership or a general training-platform owner
• widen only through ordinary owned enhancement work

cubing/qqTimer

Decision date:

• 2026-05-27

Current licensing judgment:

• the repo is now mirrored locally
• no explicit license is visible at the checked mirror root
• the checked root surface currently lacks a standalone LICENSE, COPYING, or NOTICE file
• the checked README.md attributes the timer to Michael Gottlieb and this repo variant to Lucas Garron, but does not grant a standalone permissive code license
• treat the row as restrictive custody and license-missing
• not a live HyperTwist lane; retained supplemental timer reference only

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\qqTimer\README.md
• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\qqTimer\Makefile
• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\qqTimer\docs\index.htm
• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\qqTimer\docs\scramble_333_edit.js

Practical obligations:

• keep the mirror in restrictive custody
• do not treat the row as a direct donor-use approval
• Model B must not read this mirror
• if a later source-backed license basis appears, reopen this row selectively instead of silently flattening it back into permissive custody

Approved working posture:

• retain as a supplemental timer reference and clean-room candidate only
• use it for source inspection, legacy session-format reference, embedded scramble-menu behavior comparison, and independently owned reimplementation planning
• do not treat it as a stronger owner than Aarav2709/KubeTimr for the landed local timer subsystem slice or than cs0x7f/cstimer for the broader competitive timer benchmark/oracle slice
• do not widen from the mirror as a normal permissive donor lane

cubing/scrambles

Decision date:

• 2026-05-27

Current licensing judgment:

• the standalone cubing/scrambles repo URL is currently not publicly resolvable from this pass
• no local mirror is present
• no repo-root license signal can be checked from that standalone alias row
• maintained public scramble source surfaces are already visible elsewhere in the cubing family:
  • cubing/cubing.js via cubing/scramble
  • cubing/scramble.cubing.net
  • cubing/mark3
• when HyperTwist retains those successor repos directly, track them as their own repo rows rather than blurring them back into this alias row
• direct donor use is not cleared
• keep this row as a historical alias only, not as an active mirror-restoration target

Source basis:

• C:\Workspaces\HyperTwist\repos.manifest.json
• C:\Workspaces\HyperTwist\mirrors\permissive\cubing\cubing.js\src\cubing\scramble\index.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\cubing\cubing.js\src\docs\js.cubing.net\cubing\scramble\index.html
• C:\HyperTwist\docs\HYPERTWIST_REPO_LICENSE_EVIDENCE_AUDIT_2026-05-27.md

Practical obligations:

• do not fabricate a local mirror or assume permissive terms from older intake prose
• do not keep this row in the active mirror-restoration queue
• if scramble-generation source is needed, read the maintained public cubing family surfaces first
• if the exact standalone alias repo ever reappears publicly, re-audit it as a new source event rather than silently reviving the old expectation

Approved working posture:

• retain as a historical alias reference row only
• do not treat it as mirror-ready
• do not treat it as a donor-use lane
• do not let it keep the mirror audit in an unresolved state when maintained public scramble sources are already elsewhere in the cubing family

cubing/mark3

Decision date:

• 2026-05-27

Current licensing judgment:

• the repo is now mirrored locally
• no explicit repo-root license file is visible at the checked mirror root
• the checked root surface currently lacks a standalone LICENSE, COPYING, or NOTICE file
• the checked package.json does not declare a repo license
• treat the row as restrictive custody and license-missing
• direct donor use is not cleared
• retain as a restrictive upper-surface adjunct only

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\mark3\README.md
• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\mark3\package.json
• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\mark3\src\scramble-generation\index.ts
• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\mark3\src\fixtures\testCompetitionScramblesSpec.ts

Practical obligations:

• keep the mirror in restrictive custody
• do not assume permissive terms from the public repo visibility alone
• Model B must not read this mirror
• if a later source-backed license basis appears, reopen this row selectively instead of silently flattening it into permissive custody

Approved working posture:

• retain as a seeded competition / round / attempt workflow adjunct above the already retained cubing/cubing.js scramble engine
• use it for source inspection, WCIF-shaped fixture comparison, and independently owned reimplementation planning
• do not treat it as scramble-engine ownership, because the current source delegates actual scramble generation to cubing/scramble and still leaves seed derivation as TODO
• do not widen from the mirror as a normal permissive donor lane

cubing/scramble.cubing.net

Decision date:

• 2026-05-27

Current licensing judgment:

• the repo is now mirrored locally
• no explicit repo-root license file is visible at the checked mirror root
• the checked root surface currently lacks a standalone LICENSE, COPYING, or NOTICE file
• the checked package.json declares GPL-3.0-or-later
• treat that as repo-local metadata-only license evidence, not as the same tier as a clear root license file
• keep the row in restrictive custody and treat it as strong copyleft
• direct donor use is not cleared

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\scramble.cubing.net\package.json
• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\scramble.cubing.net\README.md
• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\scramble.cubing.net\src\scramble.ts
• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\scramble.cubing.net\src\index.html

Practical obligations:

• keep the mirror in restrictive custody
• preserve the distinction between metadata-only license evidence and a clear repo-root license file
• Model B must not read this mirror
• do not treat the public webapp shell as permission for direct donor reuse

Approved working posture:

• retain as a public scramble operator-shell adjunct above the already retained cubing/cubing.js and cubing/twisty.js seams
• use it for source inspection, event-selection UX reference, refresh-workflow comparison, URL-state behavior, and independently owned reimplementation planning
• do not treat it as scramble-engine or visualization ownership, because the current source imports randomScrambleForEvent from cubing/scramble and uses cubing/twisty for the player shell
• do not widen from the mirror as a normal permissive or direct-integration lane

cubing/scramble-display

Decision date:

• 2026-05-27

Current licensing judgment:

• the repo is now mirrored locally
• the checked root LICENSE.md resolves to GPL-3.0-or-later
• keep the row in restrictive custody and treat it as strong copyleft
• the repo is scramble-display specific and sits above already tracked cubing.js and twisty.js surfaces
• direct donor use is not cleared

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\scramble-display\LICENSE.md
• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\scramble-display\README.md
• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\scramble-display\src\scramble-display\index.ts
• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\scramble-display\src\scramble-display\ScrambleDisplay.ts

Practical obligations:

• keep the mirror in restrictive custody
• Model B must not read this mirror
• do not treat this wrapper surface as permission to bypass the stricter cubing.js / twisty.js lane boundaries
• preserve it as a comparison surface rather than a direct donor-use approval

Approved working posture:

• retain as a scramble-display comparison surface only
• use it as a wrapper-convenience reference above the already retained cubing/twisty.js visualization seam
• do not treat it as a new visualization owner lane, because the current custom element is a thin TwistyPlayer wrapper
• use it for source inspection, display-shell behavior reference, and bounded clean-room planning if a first-party equivalent is ever needed
• do not widen from the mirror as a normal permissive donor lane

onionhoney/roux-trainers

Decision date:

• 2026-04-27
• refreshed on 2026-05-13

Current licensing judgment:

• GPL-3.0
• treat as restrictive clean-room only
• do not use directly in a proprietary HyperTwist core
• this lane is already implemented/live in HyperTwist only through the accepted clean-room chain

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\onionhoney\roux-trainers
• C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\43-onionhoney-roux-trainers-clean-room-dossier.md
• C:\Workspaces\HyperTwist\clean-room-specs\onionhoney-roux-trainers.model-a.md
• C:\Workspaces\HyperTwist\clean-room-specs\onionhoney-roux-trainers.model-b.md
• C:\HyperTwist\docs\HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md
• C:\HyperTwist\docs\HYPERTWIST_ROUX_METHOD_STAGE_CLEAN_ROOM_HIERARCHY_RECONCILIATION_2026-05-27.md

Practical obligations:

• keep the donor mirror in restrictive custody
• keep the Model A / Model B lineage explicit
• preserve the first-party landed-state evidence and scrubbed handoff visibility
• never treat the already-landed state as permission for direct mirror reuse

Approved working posture:

• preserve the repo as a landed restrictive clean-room precedent only
• preserve the landed bounded Roux method-stage and blockbuilding family as a first-party output family above the clean-room lineage
• do not treat the existing clean-room implementation work as permission for later direct source reuse
• start future widening from first-party outputs and scrubbed clean-room specs only

Other tracked decisions

cutelyaware/magiccube4d

Decision date:

• 2026-04-24
• refreshed on 2026-05-13
• refreshed on 2026-05-27
• refreshed on 2026-05-21

Current licensing judgment:

• usable for HyperTwist
• not blocked
• treat as a custom permissive, attribution-request license

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\cutelyaware\magiccube4d\LICENSE.md
• C:\HyperTwist\zippedreposource\magiccube4d-master.zip

Practical obligations:

• preserve the upstream copyright notice
• provide proper attribution in a natural product-facing place
• include a link to http://superliminal.com/cube/cube.htm
• preserve the upstream license text in third-party notices or equivalent release/legal materials

Recommended attribution handling:

• Help > About
• third-party notices file
• source comments near vendored or closely adapted code
• release/license declarations

Tracked provenance note:

• HyperTwist also possesses a local source archive:
  • C:\HyperTwist\zippedreposource\magiccube4d-master.zip
• current HyperTwist posture:
  • use the mirrored cutelyaware/magiccube4d repo plus its LICENSE.md as the canonical legal basis
  • retain the zip as duplicate source possession and provenance context, not as a separate unresolved legal lane
• src/com/donhatchsw/util/MyMath.java contains a comment stating that one log1p formulation was found in GSL GPL version 2, while also suggesting the underlying numerical method traces back to Kahan
• current HyperTwist posture: record that note, preserve attribution/provenance context, and avoid pretending the repo is a zero-friction plain-MIT transplant
• current blocker status: not a blocker

Approved working posture:

• treat cutelyaware/magiccube4d as a landed attributed first-party legacy 4D lane with preserved attribution and notice obligations
• do not force it into the clean-room-only lane
• do not keep it in the Model B forbidden by default bucket merely because the license text is custom rather than OSI-template
• preserve the landed Phase 4R-B packet as the implementation-facing authority for history, macro, topology-reference, interaction, and provenance-boundary scope

cubing/cubing.js

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• usable for HyperTwist
• not a plain permissive license
• treat as a dual MPL-2.0 OR GPL-3.0-or-later dependency, with the practical integration path based on the MPL side
• this row is not a clean-room requirement under current HyperTwist doctrine

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\cubing\cubing.js\package.json
• C:\Workspaces\HyperTwist\mirrors\permissive\cubing\cubing.js\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\cubing\cubing.js\LICENSE-MPL.md
• C:\Workspaces\HyperTwist\mirrors\permissive\cubing\cubing.js\LICENSE-GPL.md

Practical obligations:

• if HyperTwist uses cubing.js as a library, keep the upstream notices and license materials intact
• if HyperTwist modifies cubing.js source files, those modifications to the cubing.js source itself must be published
• preserve third-party notices for vendored code and assets where required

Recommended working posture:

• prefer package dependency, adapter boundary, or sidecar/library consumption
• avoid deep private forks unless you are prepared to publish the modified cubing.js source files
• treat it as a strong semantic/runtime donor for classic-cubing state, notation, scramble, rendering, and smartcube integration, but not as the proprietary core you freely rewrite in place without consequences

Current landed posture added on 2026-05-13:

• Phase 4R-A is now closed
• cubing/cubing.js is now live in checked Unreal surfaces as a first-party classic-cubing semantic/runtime adapter lane
• no upstream cubing.js source files were modified in that landed packet
• keep the practical MPL path explicit in future widening; if HyperTwist later edits upstream-covered files directly, publish those source-file modifications
• do not reclassify this row as a restrictive clean-room lane unless the governing license posture or implementation route changes materially

cubing/alg.js

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• explicit GPL-3.0-or-later
• do not use directly in a proprietary HyperTwist core
• keep in restrictive custody
• approved as a separate clean-room donor target

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\alg.js\package.json
• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\alg.js\LICENSE.md

Approved working posture:

• do not fold this repo away just because cubing.js also covers algorithm semantics
• treat it as its own Model A extraction line for parser, AST, traversal, validation, keyboard, and URL/interchange semantics
• Model B must not read the mirror
• Model B may only consume C:\Workspaces\HyperTwist\clean-room-specs\cubing-alg-js.model-a.md
• current 2026-05-27 reconciliation overlay:
  • the bounded first-party HyperTwistAlgorithm/* owner lane is verified live and closed through Bound 4
  • the landed owner slice is parser, AST, traversal, validation, keyboard mapping, and share/interchange semantics only
  • checked training-runtime parse/store/serialize adoption stays a consumer seam above that owner lane
  • do not reopen the closed owner lane by default; later work must be a new consumer-owner or shell packet if justified

cubing/twisty.js

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• explicit GPL-3.0-or-later
• do not use directly in a proprietary HyperTwist core
• keep in restrictive custody
• approved as a separate clean-room donor target

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\twisty.js\package.json
• C:\Workspaces\HyperTwist\mirrors\restrictive\cubing\twisty.js\LICENSE.md

Approved working posture:

• do not collapse this repo into the broader cubing.js lane for custody purposes
• treat it as its own Model A extraction line for compact viewer/player architecture, scrubber/control-bar semantics, animation/cursor observers, puzzle adapters, and embedded <twisty> element behavior
• Model B must not read the mirror
• Model B may only consume C:\Workspaces\HyperTwist\clean-room-specs\cubing-twisty-js.model-a.md
• current 2026-05-27 reconciliation overlay:
  • the bounded first-party HyperTwistSimulation replay/player and visualization owner lane is verified live and closed through Bound 4
  • the landed owner slice is player shell, cursor/timeline transport, adapter/bootstrap, and local visualization/fallback presentation behavior
  • keep classic-cubing semantics with cubing/cubing.js, parser/AST ownership with cubing/alg.js, and broader browser support ownership with the landed browser support lanes
  • do not reopen the closed owner lane by default; later work must be a new consumer-owner or shell packet if justified

cahidenes/rubiks-cube-solver

Decision date:

• 2026-05-13
• refreshed on 2026-05-27

Current licensing judgment:

• explicit MIT
• repo code is usable for HyperTwist under the checked permissive license text
• not a clean-room case
• treat as a bounded recognition-comparison adjunct donor behind the retained recognition anchors

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\cahidenes\rubiks-cube-solver\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\cahidenes\rubiks-cube-solver\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\cahidenes\rubiks-cube-solver\rubiks-cube-solver.py

Important distinction:

• the checked mirror does contain a top-level LICENSE, so this row is not in the same confidence posture as tentone/rubix-solver
• the strongest current product value is not a primary recognition shell, but a narrow comparison lane:
  • face-orientation fill logic
  • cube-string assembly from partial capture
  • lightweight HSV and per-sticker bookkeeping
  • two-opposite-corner fast-recognition assumptions as an optional adjunct heuristic
• that makes it useful for validation and cross-checking behind the retained recognition anchors, not for primary calibration, reconstruction, or product-shell ownership

Approved working posture:

• HyperTwist may use the codebase directly under the checked MIT posture
• keep it subordinate to the retained kkoomen/qbr and vivaansinghvi07/rubix-cube-solver lanes
• do not let it expand into the primary recognition, calibration, or correction shell
• no default widening packet is open today; reopen only if a narrower face-placement, cube-string, or divergence-reporting gap is later proven above the landed recognition stack
• use any later widening only through the retained comparison-adjunct route authority defined by Phase 2R-C plus the 2026-05-27 recognition-comparison hierarchy reconciliation

kkoomen/qbr

Decision date:

• 2026-05-20

Current licensing judgment:

• explicit MIT
• repo code is usable for HyperTwist under the checked permissive license text
• not a clean-room case
• treat as the retained recognition-substrate donor whose first narrower bounded slice is now landed in current code

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\kkoomen\qbr\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\kkoomen\qbr\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\kkoomen\qbr\src\qbr.py
• C:\Workspaces\HyperTwist\mirrors\permissive\kkoomen\qbr\src\colordetection.py
• C:\Workspaces\HyperTwist\mirrors\permissive\kkoomen\qbr\src\video.py

Important distinction:

• the strongest current value is the bounded recognition substrate:
  • webcam-driven capture loop
  • calibration flow
  • color-detection bookkeeping
  • multilingual solve guidance shell
• the first landed HyperTwist slice is intentionally narrower than that broader donor value:
  • classic-cube recognition calibration contract
  • ordered face-observation contract
• permissive posture alone does not let it outrank the already accepted route sequencing or absorb the whole product recognition shell prematurely
• the checked mirror also contains a bundled font asset:
  • C:\Workspaces\HyperTwist\mirrors\permissive\kkoomen\qbr\src\assets\arial-unicode-ms.ttf
• no separate font license surfaced in this shallow legal pass, so direct redistribution of that asset should be separately confirmed or replaced before shipping it as-is

Approved working posture:

• HyperTwist may use the codebase directly under the checked MIT posture
• preserve the upstream MIT license text and copyright notice:
  • Copyright (c) 2016 Kim Koomen
• keep the row as a partially incorporated recognition-substrate donor, not as a blanket promotion to full recognition-shell ownership
• the landed packets are bounded to:
  • classic-cube recognition calibration contract
  • ordered face-observation contract
  • classic-cube webcam shell
  • locale-aware solve-guidance routing overlay above the already landed shared explanation stack
  • multilingual solve-shell presentation posture above the already landed locale-routing overlay
  • bundled-font review profiles, per-locale review-descriptor routing, and active review-state posture above the already landed locale-routing plus locale-presentation seams
  • shared correction-target capture-state and re-scan adjunct via the landed shared Phase 6R-R and Phase 6R-S correction shell
• keep the following families deferred to later queue decisions:
  • bundled-font redistribution
  • direct standalone multilingual solve-shell rendering or asset-shipping widening beyond the landed shared correction adjunct, bounded locale-routing plus locale-presentation seams, and the landed review boundary
• if later implementation copies bundled non-code assets, capture and preserve any asset-specific license or replace the asset with a clearly redistributable alternative

vivaansinghvi07/rubix-cube-solver

Decision date:

• 2026-05-20

Current licensing judgment:

• explicit MIT
• repo code is usable for HyperTwist under the checked permissive license text
• not a clean-room case
• treat as the retained recognition-companion and correction-flow donor behind kkoomen/qbr

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\vivaansinghvi07\rubix-cube-solver\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\vivaansinghvi07\rubix-cube-solver\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\vivaansinghvi07\rubix-cube-solver\backend\cv.py
• C:\Workspaces\HyperTwist\mirrors\permissive\vivaansinghvi07\rubix-cube-solver\backend\server.py
• C:\Workspaces\HyperTwist\mirrors\permissive\vivaansinghvi07\rubix-cube-solver\frontend\src\script.js

Important distinction:

• the strongest current value is not the whole repo shell; it is the narrower companion lane:
  • cube-read reconstruction flow
  • browser-assisted interaction shell
  • solver-explanation and correction-side heuristics
• the checked frontend includes a bundled third-party minified asset:
  • C:\Workspaces\HyperTwist\mirrors\permissive\vivaansinghvi07\rubix-cube-solver\frontend\lib\twistysim.min.js
• do not assume that bundled dependency is covered only by the repo's own MIT without preserving its upstream provenance and license when redistributed
• keep the repo subordinate to route packets and to the stronger queued recognition-substrate order rather than letting permissive posture alone promote it into the primary owner shell

Approved working posture:

• HyperTwist may use the checked repo directly under the upstream MIT posture
• preserve the upstream MIT license text and copyright notice:
  • Copyright (c) 2023 Vivaan Singhvi
• preserve the row as the bounded recognition companion lane after kkoomen/qbr
• if later implementation ships or copies bundled third-party frontend assets, capture and preserve those assets' own upstream license/provenance rather than flattening them into the repo-level MIT
• the bounded retained slices now landed in current code are:
  • committed-face reconstruction session
  • face-vote replacement ledger
  • final classic-net shaping above aggregated committed faces
  • browser/webcam shell profile and browser-shell session-state composition
  • bounded solve explanation/recommendation stage ladder and recommendation state
  • bundled browser visualization asset review profiles, descriptor routing, and active review state for the retained twistysim.min.js asset boundary
  • bounded correction profile, contradiction-aware correction state, and correction-explanation shell routing
  • correction-resolution ledger, manual-review acceptance, and solve-guidance reopen/unlock semantics
• keep the row only partially incorporated by default:
  • any redistribution or shipping of frontend/lib/twistysim.min.js still requires preserved or replaced upstream provenance/license beyond the landed review boundary
  • generalized solver backend ownership and broad playback-runtime ownership stay separately deferred

tentone/rubix-solver

Decision date:

• 2026-04-24
• refreshed on 2026-05-13
• refreshed on 2026-05-27

Current licensing judgment:

• treat as permissive enough to remain active
• practical working assumption: MIT
• confidence is weaker than a repo with a bundled top-level license file

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\tentone\rubix-solver\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\tentone\rubix-solver\vision.cpp
• C:\Workspaces\HyperTwist\mirrors\permissive\tentone\rubix-solver\cube.cpp
• public repo page observed on 2026-04-24

Important caveat:

• the mirrored source tree does not contain a top-level LICENSE file
• the MIT posture is asserted by upstream README/repo presentation rather than proven by a bundled license text in the mirror
• the strongest current product value is not the brute-force solve shell, but a narrow native comparison lane:
  • quad clustering and ordering
  • square-mask color sampling
  • center-color face identification
  • lightweight native face-array and state-mutation comparison behavior
• that makes it useful as a bounded native recognition comparator behind the landed first-party recognition stack, not as a primary recognition, correction, or solver owner

Approved working posture:

• keep active as a strategic donor
• preserve the upstream README licensing statement in the evaluation record
• if HyperTwist later vendors code directly from this repo, capture and retain the final authoritative upstream license text at that time rather than relying only on the current mirror
• keep it subordinate to the landed kkoomen/qbr, vivaansinghvi07/rubix-cube-solver, and first-party correction-stack seams
• explicitly exclude the brute-force solve shell and local camera shell from owned HyperTwist functionality
• no default widening packet is open today; reopen only if a narrower native quad, mask, or divergence-reporting gap is later proven above the landed recognition stack

NuiLab/code-vr

Decision date:

• 2026-05-13
• refreshed on 2026-05-27

Current licensing judgment:

• explicit MIT
• repo code is usable for HyperTwist under the checked permissive license text
• not a clean-room case
• treat as a bounded symbolic-to-spatial pedagogy experiment donor only

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\NuiLab\code-vr\license.md
• C:\Workspaces\HyperTwist\mirrors\permissive\NuiLab\code-vr\readme.md
• C:\Workspaces\HyperTwist\mirrors\permissive\NuiLab\code-vr\codevr\src\main.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\NuiLab\code-vr\codevr\src\app\player.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\NuiLab\code-vr\languages\python\parse.py
• C:\Workspaces\HyperTwist\mirrors\permissive\NuiLab\code-vr\languages\client\src\main.rs

Important distinction:

• the checked mirror does contain a top-level license.md, so the permissive posture is source-backed
• the strongest current product value is not the game shell or XR runtime itself, but a narrow concept lane:
  • symbolic structures converted into traversable space
  • parse/export/runtime separation
  • spatial pedagogy around abstract structure
  • multi-process teaching-sidecar behavior
• that makes it useful for later experimental teaching surfaces, not for direct ownership of HyperTwist's XR runtime, gameplay shell, or code-intelligence product direction

Approved working posture:

• HyperTwist may use the codebase directly under the checked MIT posture
• keep it bounded as a symbolic-to-spatial pedagogy experiment donor only
• keep practical XR runtime ownership with the retained pmndrs/xr lane and broader product runtime ownership outside this donor
• no default widening packet is open today; reopen only if a narrower symbolic-to-spatial pedagogy gap is later proven above the landed knowledge and browser-spatial/XR stack
• use any later widening only through the experiment route authority defined by Phase 2R-C plus the 2026-05-27 symbolic-XR and alternative-browser reconciliation

kash/cubedesk

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• contradictory inside the repo materials
• do not treat as a clean direct donor
• keep in restrictive clean-room custody

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\kash\cubedesk\README.md
• C:\Workspaces\HyperTwist\mirrors\restrictive\kash\cubedesk\LICENSE.md
• C:\Workspaces\HyperTwist\mirrors\restrictive\kash\cubedesk\package.json

Observed contradiction:

• README.md says the project is licensed under GPL version 3 or later
• LICENSE.md is GPLv3
• package.json says CubeDesk, Inc. All Rights Reserved

Approved working posture:

• do not rely on direct code use
• do not rely on a naive GPL-only assumption without resolving the contradiction
• keep the mirror in restrictive custody
• treat the repo as a clean-room strategic donor for product-subsystem extraction only
• preserve it as the primary clean-room donor for trainer-session coupling, solve/session/training-session/game-session boundaries, integrated smart-cube workflow composition, and multiplayer / leaderboard product patterns
• do not blur this row into the already landed Aarav2709/KubeTimr local timer subsystem slice
• do not blur this row into the broader cs0x7f/cstimer competitive timer, scramble, and smart-device benchmark/oracle slice
• current 2026-05-27 live-status overlay:
  • bounded first-party clean-room implementation is already landed and closed through Bound 5
  • the closed slices are trainer-session coupling, session-domain and analytics-panel surfaces, integrated smart-device workflow composition with local persistence policy, publication/leaderboard projection with entitlement gating, and local social challenge support
  • keep the row visible as the restrictive source authority for those landed bounds without flattening it into direct donor-use approval
  • do not reopen Bound 1 through Bound 5 by default; any future work must be a later-bound or widening packet if justified

cs0x7f/cstimer

Decision date:

• 2026-04-27

Current licensing judgment:

• treat as restrictive
• do not use directly in a proprietary HyperTwist core
• keep in restrictive custody
• approved for planning as:
  • clean-room timer-pattern candidate
  • behavioral benchmark
  • future timer and analytics parity reference

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\cs0x7f\cstimer
• C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\41-cs0x7f-cstimer-upstream-dossier.md
• C:\HyperTwist\docs\HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md
• C:\HyperTwist\docs\HYPERTWIST_CSTIMER_BENCHMARK_ORACLE_AND_REOPEN_CRITERIA_RECONCILIATION_2026-05-27.md

Approved working posture:

• do not read it into clean implementation lanes
• use it as the primary restrictive benchmark and planning reference for competition-grade inspection or multi-phase timing semantics, rolling stats/average or DNF math, session/import-export parity, broader scramble-registry behavior, and GAN/smart-device expectations
• preserve the distinction between the broader cstimer oracle slice and the narrower already landed KubeTimr local timer subsystem slice
• preserve the distinction between this broader oracle slice and kash/cubedesk as the retained clean-room owner for trainer-session, solve/session, and integrated smart-cube workflow product patterns
• do not treat the browser/PWA shell as the retained center of gravity
• preserve its 0R-E status as the primary restrictive timer/stats/scramble/smart-device oracle row
• if a future first-party gap is proven in timing semantics, stats parity, session interchange, scramble breadth, or smart-device behavior, route it through a dedicated clean-room timer-pattern handoff rather than ordinary donor intake

efrantar/rob-twophase

Decision date:

• 2026-04-27

Current licensing judgment:

• treat as restrictive
• do not use directly in a proprietary HyperTwist core
• keep in restrictive custody
• approved for planning as a benchmark oracle, not as a normal donor

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\efrantar\rob-twophase
• C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\40-efrantar-rob-twophase-upstream-dossier.md
• C:\HyperTwist\docs\HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md

Approved working posture:

• use as a correctness and solver-quality reference only
• do not expose it to clean implementation lanes
• preserve brownan/Rubiks-Cube-Solver as the primary compact correctness and heuristic-table oracle
• preserve this row as the retained metric, pruning, robot-execution, and performance comparator rather than the first clean-room target
• do not blur the current landed Phase 6R-Q, Phase 6R-R, and Phase 6R-S shell/state families into a claim of implemented generalized solver-backend ownership
• preserve its 0R-E status as a secondary solver oracle focused on metric and performance comparison
• preserve its benchmark-oracle role explicitly in later validation and Phase 8 planning docs

brownan/Rubiks-Cube-Solver

Decision date:

• 2026-05-13

Current licensing judgment:

• GPL-3.0
• treat as restrictive
• do not use directly in a proprietary HyperTwist core
• retain as:
  • compact solver oracle
  • heuristic/search clean-room-later benchmark

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\brownan\Rubiks-Cube-Solver\README.rst
• C:\Workspaces\HyperTwist\mirrors\restrictive\brownan\Rubiks-Cube-Solver\cube.c
• C:\Workspaces\HyperTwist\mirrors\restrictive\brownan\Rubiks-Cube-Solver\goal.c
• C:\Workspaces\HyperTwist\mirrors\restrictive\brownan\Rubiks-Cube-Solver\main.c
• C:\HyperTwist\docs\HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md

Approved working posture:

• preserve it as the primary compact restrictive solver oracle from 0R-E
• do not blur the current landed Phase 6R-Q, Phase 6R-R, and Phase 6R-S shell/state families into a claim of implemented generalized solver-backend ownership
• preserve efrantar/rob-twophase as the retained robot-metric and performance comparator rather than the first clean-room target
• if HyperTwist later opens a first-party classic solver lane, start from scrubbed first-party contracts rather than direct source reuse
• keep the current brownan-rubiks-cube-solver.model-a.md and .oracle.md files subordinate to the 0R-E packet authority

aMonteSl/CodeXR

Decision date:

• 2026-05-13

Current licensing judgment:

• GPL-3.0-only
• treat as restrictive
• discard from the active HyperTwist retained set

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\aMonteSl\CodeXR\README.md
• C:\Workspaces\HyperTwist\mirrors\restrictive\aMonteSl\CodeXR\src\extension.ts
• C:\Workspaces\HyperTwist\mirrors\restrictive\aMonteSl\CodeXR\src\core\startup\startupCoordinator.ts
• C:\Workspaces\HyperTwist\mirrors\restrictive\aMonteSl\CodeXR\src\servers\runtime\multiServerLauncher.ts
• C:\Workspaces\HyperTwist\mirrors\restrictive\aMonteSl\CodeXR\templates\components\codexr\virtual-screen\virtualScreenRuntime.js
• C:\HyperTwist\docs\HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md
• C:\HyperTwist\docs\HYPERTWIST_CODEXR_OFF_DOMAIN_XR_COLLABORATION_DISCARD_CONFIRMATION_RECONCILIATION_2026-05-27.md

Approved working posture:

• do not schedule donor, clean-room, or implementation work from this row
• if later XR collaboration ideas are compared historically, keep that comparison conceptual and bounded
• the active retained set should rely on already-kept XR/runtime/capture rows instead
• discard-confirmed on 2026-05-27: no surviving unique HyperTwist lane remains above retained pmndrs/xr, screenpipe/screenpipe, PostHog/posthog, and remotion-dev/remotion

MathewKJ2048/Rubiks-cube-simulator

Decision date:

• 2026-05-13

Current licensing judgment:

• GPL-3.0
• treat as restrictive
• discard from the active HyperTwist retained set

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\MathewKJ2048\Rubiks-cube-simulator\README.md
• C:\Workspaces\HyperTwist\mirrors\restrictive\MathewKJ2048\Rubiks-cube-simulator\src\Main.java
• C:\Workspaces\HyperTwist\mirrors\restrictive\MathewKJ2048\Rubiks-cube-simulator\src\GUI_Cube.java
• C:\Workspaces\HyperTwist\mirrors\restrictive\MathewKJ2048\Rubiks-cube-simulator\src\Cube_solver.java
• C:\Workspaces\HyperTwist\mirrors\restrictive\MathewKJ2048\Rubiks-cube-simulator\src\cube\Cube.java
• C:\HyperTwist\docs\HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md

Approved working posture:

• do not continue active clean-room planning from this row
• treat any preexisting scrubbed handoff material for this repo as historical only
• current 2026-05-27 reconciliation overlay:
  • repo-local extraction unchanged
  • source-backed comparison confirmed the discard remains correct
  • no surviving unique retained slice remains after comparison against the current first-party replay/history family and the retained AviKaufman, alinen, and CubeSim rows
  • do not interpret the scrubbed Model A note as active implementation authority
• prefer AviKaufman/Rubix-cube-trainer, alinen/cube, and vwcwong/CubeSim for the surviving pedagogy/planner/history benchmark surfaces

ShellPuppy/RCube

Decision date:

• 2026-05-13

Current licensing judgment:

• GPL-3.0
• treat as restrictive
• retain as:
  • large-N algorithm benchmark
  • later clean-room research input

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\ShellPuppy\RCube\README.md
• C:\Workspaces\HyperTwist\mirrors\restrictive\ShellPuppy\RCube\RCube\Cube.h
• C:\Workspaces\HyperTwist\mirrors\restrictive\ShellPuppy\RCube\RCube\Cube.cpp
• C:\Workspaces\HyperTwist\mirrors\restrictive\ShellPuppy\RCube\RCube\CubeViewer.cpp
• C:\HyperTwist\docs\HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md

Approved working posture:

• keep it as benchmark/reference only
• treat it as A1 + R4 + F2 only for the exact retained large-N classic-cube center-stage, edge-pairing/parity, and virtual-rotation strategy slice
• do not treat it as a near-term implementation donor, a hyper-runtime owner, or proof that a live large-N classic-cube solver backend already exists
• preserve the landed Hyperspeedcube, MagicTile, Magic120Cell, and MagicCube5D packets as the current implemented higher-dimensional runtime owners
• do not reopen the bounded classic-cube Phase 6R-Q, Phase 6R-R, and Phase 6R-S shell/state families from this row
• revisit only if HyperTwist later opens an explicit large-cube widening lane above the current first-party families

vwcwong/CubeSim

Decision date:

• 2026-05-13

Current licensing judgment:

• GPL-3.0
• treat as restrictive
• retain as clean-room-later benchmark material

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\vwcwong\CubeSim\README.md
• C:\Workspaces\HyperTwist\mirrors\restrictive\vwcwong\CubeSim\src\cube\cube.py
• C:\Workspaces\HyperTwist\mirrors\restrictive\vwcwong\CubeSim\src\cube\history_cube.py
• C:\Workspaces\HyperTwist\mirrors\restrictive\vwcwong\CubeSim\src\scramble\generator.py
• C:\Workspaces\HyperTwist\mirrors\restrictive\vwcwong\CubeSim\src\cube\solver.py
• C:\HyperTwist\docs\HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md

Approved working posture:

• keep it as A1 + R4 + F2 only for the exact retained readable renderer-independent classic-cube state/history split, scramble parse or invert behavior, and beginner LBL decomposition benchmark slice
• do not use it directly in first-party HyperTwist and do not treat it as a live replay/history owner or explanation-shell owner
• preserve the first-party canonical replay packet, training attempt/solve/review history, and bounded classic-cube Phase 6R-Q, Phase 6R-R, and Phase 6R-S seams as the current live owners
• preserve the existing scrubbed handoff only as a later clean-room seed beneath the 0R-E packet authority

AviKaufman/Rubix-cube-trainer

Decision date:

• 2026-05-13

Current licensing judgment:

• All Rights Reserved
• retain only as clean-room pedagogy benchmark material
• direct incorporation is not permitted

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\AviKaufman\Rubix-cube-trainer\README.md
• C:\Workspaces\HyperTwist\mirrors\restrictive\AviKaufman\Rubix-cube-trainer\package.json
• C:\Workspaces\HyperTwist\mirrors\restrictive\AviKaufman\Rubix-cube-trainer\src\main.ts
• C:\HyperTwist\docs\HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md

Approved working posture:

• keep it as A1 + R4 + F2 only for the exact retained named-milestone lesson-state, oversatisfied-step explanation, bounded step-help, and manual-turn/tutorial-coherence pedagogy benchmark slice
• do not treat it as a live training-session owner, coaching backend owner, or bounded solve-guidance owner
• preserve the current first-party training-session, method-drill, coaching queue/follow-up, and bounded classic-cube Phase 6R-Q, Phase 6R-R, and Phase 6R-S seams as the live owners
• any future first-party lesson work must proceed through scrubbed clean-room behavior contracts only
• preserve the existing model-a file only as a bounded seed beneath the packet authority

alinen/cube

Decision date:

• 2026-05-13

Current licensing judgment:

• no explicit license visible
• do not incorporate source directly
• retain only as clean-room planner benchmark material

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\alinen\cube\README.md
• C:\Workspaces\HyperTwist\mirrors\restrictive\alinen\cube\Assets\Scripts\CubePlanner.cs
• C:\Workspaces\HyperTwist\mirrors\restrictive\alinen\cube\Assets\Scripts\CubeTaskSolver.cs
• C:\Workspaces\HyperTwist\mirrors\restrictive\alinen\cube\Assets\Scripts\CubeStateManager.cs
• C:\Workspaces\HyperTwist\mirrors\restrictive\alinen\cube\Assets\Scripts\CubeController.cs
• C:\HyperTwist\docs\HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md

Approved working posture:

• keep as an A1 + R4 + F2 clean-room benchmark only for the retained lesson-task graph, bounded task-local planner, focus-target cueing, and queued move-demonstration slice
• do not reinterpret the current first-party training-session, method-drill, coaching queue/follow-up, canonical replay, or bounded classic-cube Phase 6R-Q, Phase 6R-R, and Phase 6R-S shell/state families through this row
• do not route direct donor work from this row
• preserve the existing model-a file only as bounded seed material beneath the packet authority

ambisinister/blindsolve

Decision date:

• 2026-05-13

Current licensing judgment:

• no explicit license visible
• do not incorporate source directly
• retain only as clean-room BLD memo benchmark material

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\ambisinister\blindsolve\README.md
• C:\Workspaces\HyperTwist\mirrors\restrictive\ambisinister\blindsolve\main.py
• C:\Workspaces\HyperTwist\mirrors\restrictive\ambisinister\blindsolve\cube.py
• C:\Workspaces\HyperTwist\mirrors\restrictive\ambisinister\blindsolve\algs.py
• C:\HyperTwist\docs\HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md

Approved working posture:

• keep as an A1 + R4 + F2 benchmark only for the retained blindfold memo attempt-phase, conceal/reveal validation, letter-pair token input, parity-aware memo expectation, and lightweight repeat-cadence slice
• do not reinterpret the current first-party timing-policy templates, coaching-memory/follow-up surfaces, replay-verification blindfold event taxonomy, or broader memory doctrine through this row
• do not widen it into general trainer ownership
• preserve the existing model-a file only as bounded seed material beneath the packet authority

brianpeiris/RiftSketch

Decision date:

• 2026-05-13
• 2026-05-27

Current licensing judgment:

• MIT
• discard from the active HyperTwist retained set

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\brianpeiris\RiftSketch\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\brianpeiris\RiftSketch\js\Sketch.js
• C:\Workspaces\HyperTwist\mirrors\permissive\brianpeiris\RiftSketch\js\SketchController.js
• C:\Workspaces\HyperTwist\mirrors\permissive\brianpeiris\RiftSketch\js\RiftSandbox.js
• C:\Workspaces\HyperTwist\mirrors\permissive\brianpeiris\RiftSketch\js\File.js
• C:\HyperTwist\docs\HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md
• C:\HyperTwist\docs\HYPERTWIST_RIFTSKETCH_IMMERSIVE_LIVE_CODING_DISCARD_CONFIRMATION_RECONCILIATION_2026-05-27.md

Approved working posture:

• do not schedule implementation work from this row
• keep it only as historical immersive live-coding comparison context for world-space monitor, text-entry, and live scene-update interaction notes
• do not reinterpret the current browser/XR, browser-spatial, capture/history, or export owners through this row

yakupbilen/drl-rubiks-cube

Decision date:

• 2026-05-13

Current licensing judgment:

• MIT
• retain as research and experimentation benchmark material
• not approved as a broad product donor
• approved only as the benchmark basis for the landed first-party Phase 6R-AV through Phase 6R-AZ learned-search lane

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\yakupbilen\drl-rubiks-cube\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\yakupbilen\drl-rubiks-cube\cube\cube.py
• C:\Workspaces\HyperTwist\mirrors\permissive\yakupbilen\drl-rubiks-cube\search\search.py
• C:\Workspaces\HyperTwist\mirrors\permissive\yakupbilen\drl-rubiks-cube\search\node.py
• C:\Workspaces\HyperTwist\mirrors\permissive\yakupbilen\drl-rubiks-cube\search\search_utils.py
• C:\Workspaces\HyperTwist\mirrors\permissive\yakupbilen\drl-rubiks-cube\train\train_utils.py
• C:\Workspaces\HyperTwist\mirrors\permissive\yakupbilen\drl-rubiks-cube\networks\modelpaper.py
• C:\HyperTwist\docs\HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md
• C:\HyperTwist\docs\HYPERTWIST_LEARNED_HEURISTIC_SEARCH_AND_OFFLINE_SOLVER_RESEARCH_HIERARCHY_RECONCILIATION_2026-05-27.md

Approved working posture:

• keep as a permissive research bench for 54-sticker transition encoding, ADI state generation, batched neural search experiments, and offline solver experimentation
• keep the landed first-party Phase 6R-AV lane bounded to experiment-profile, ADI, search-benchmark, and attribution contracts above that benchmark slice
• keep the landed first-party Phase 6R-AW refinement bounded to sequence-policy and search-budget contracts above the same benchmark slice
• keep the landed first-party Phase 6R-AX refinement bounded to node-identity and state-expansion contracts above the same benchmark slice
• keep the landed first-party Phase 6R-AY refinement bounded to frontier-scoring and solution-unwind contracts above the same benchmark slice
• keep the landed first-party Phase 6R-AZ refinement bounded to value-network shape and generator-sync contracts above the same benchmark slice
• do not treat it as a live camera, calibration, reconstruction, or browser shell owner
• preserve qbr and rubix-cube-solver as the live recognition/reconstruction owners
• preserve brownan and efrantar as the retained correctness/performance solver-oracle owners
• do not let permissive status alone promote it into the committed perception/training/runtime core
• do not widen the landed first-party lane into live perception, solver-oracle, or deployed model-serving ownership

HactarCE/2x2x2x2-Scrambler

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• explicit GPL-3.0
• do not use directly in a proprietary HyperTwist core
• keep in restrictive custody
• approved as a focused clean-room donor target

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\HactarCE\2x2x2x2-Scrambler\LICENSE
• C:\Workspaces\HyperTwist\mirrors\restrictive\HactarCE\2x2x2x2-Scrambler\src\cljc\scrambler\puzzle\core.cljc
• C:\Workspaces\HyperTwist\mirrors\restrictive\HactarCE\2x2x2x2-Scrambler\src\cljc\scrambler\puzzle\state_generator.cljc

Important provenance note:

• the source explicitly says it is a Clojure port of pentaquark394's earlier random-state scrambler
• the same comments also say some algorithms and comments/docstrings were copied nearly verbatim
• practical implication: preserve the provenance note in evaluation records and keep the repo firmly in Model A custody

Approved working posture:

• treat it as a focused restrictive clean-room donor for Melinda 2x2x2x2 random-state generation, parity/handedness logic, move-family semantics, and flat debug rendering
• Model B must not read the mirror
• Model B may only consume C:\Workspaces\HyperTwist\clean-room-specs\hactarce-2x2x2x2-scrambler.model-a.md
• current 2026-05-27 reconciliation overlay:
  • the bounded first-party HyperTwistCore Melinda owner lane is verified live and closed through Bound 4
  • the landed owner slice is state legality, random-state generation, move-family application, scramble-packet construction, and flat debug or teaching projection
  • keep broader higher-dimensional runtime ownership with adjacent live lanes and keep magiccube4d only as legacy reference context for this slice
  • do not reopen the closed owner lane by default; later work must be a new consumer-owner or widening packet if justified

HactarCE/Hyperspeedcube

Decision date:

• 2026-05-20

Current licensing judgment:

• source code is usable for HyperTwist under the checked dual-license posture:
  • MIT
  • Apache-2.0
• not a clean-room case
• treat as a bounded permissive donor candidate whose technical widening is still constrained by the retained Phase 6R-A ownership contract
• the first narrower bounded implementation slices are now landed in current code:
  • hyper puzzle catalog contract
  • hyper notation contract
  • replay-log serialization boundary
  • replay verification boundary
  • stats-shape and solve-record boundary
  • puzzle-definition DSL authoring contract and module/evaluation boundary
• the row is now closed for the currently justified retained families; no further widening is justified from this row by default

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\LICENSE-MIT
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\LICENSE-APACHE
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\Cargo.toml
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\crates\hyperpuzzle_core\src\catalog\builder.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\crates\hypuz_notation\src\unspanned.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\crates\hypuz_notation\src\spanned.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\crates\hypuz_notation\src\parse.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\crates\hyperpuzzle_log\src\lib.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\crates\hyperpuzzle_log\src\verify.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\crates\hyperspeedcube_cli_types\src\verification.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\crates\hyperpuzzle_view\src\simulation\mod.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\crates\hyperpuzzle_view\src\replay_event.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\crates\hyperspeedcube\src\app.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\crates\hyperpuzzlescript\src\lib.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\crates\hyperpuzzlescript\src\runtime\file_store.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\crates\hyperpuzzlescript\src\runtime\mod.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\crates\hyperpuzzlescript\src\engines.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\crates\hyperpuzzlescript\src\request.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\crates\hyperpuzzlescript\src\parse\parser.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\crates\hyperpuzzlescript\src\builtins\catalog\puzzles.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\crates\hyperpuzzlescript\src\codegen.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\HactarCE\Hyperspeedcube\hps\puzzles\ft_cube.hps

Important distinction:

• the code posture is permissive, but permissive status does not let the repo absorb the whole shell, packaging, or every neighboring hyper-puzzle lane
• keep the live widening inside the already accepted 2R-A contract:
  • puzzle catalog contract
  • puzzle-definition DSL authoring contract and module/evaluation boundary
  • notation grammar and serialization boundary
  • replay-event taxonomy and verification boundary
  • stats-shape and solve-record contract
• the currently landed bounded slices inside that contract are:
  • puzzle catalog contract
  • notation grammar and replay-log serialization boundary
  • replay verification and solve-proof diagnostics boundary
  • stats-shape and solve-record boundary
  • puzzle-definition DSL authoring contract and module/evaluation boundary
• the workspace includes a hypercubing_leaderboards_client crate, but that does not transfer remote service ownership or reorder the queued Phase 6R-A packet by itself

Approved working posture:

• HyperTwist may use the mirrored repo directly under the upstream dual-license posture
• if code is incorporated directly, preserve the selected upstream license text and copyright notice:
  • Copyright (c) 2025 HactarCE
• if the compliance path does not narrow to one branch cleanly, preserve both upstream license texts
• if the Apache branch is chosen for copied code, preserve ordinary Apache redistribution obligations
• treat this row as the live queue head for bounded source-backed Phase 6R-A, not as blanket permission to transplant the whole Rust application shell
• do not let this row absorb non-Euclidean topology ownership that remains queued for roice3/MagicTile
• after the landed puzzle-catalog, notation, replay-verification, stats-shape, and DSL slices, do not reopen this retained row by default unless a new bounded family is justified explicitly

coqui-ai/TTS

Decision date:

• 2026-04-24
• refreshed on 2026-05-13
• refreshed on 2026-05-22
• refreshed on 2026-05-31

Current licensing judgment:

• source code is usable for HyperTwist under MPL-2.0
• the repo is not a clean-room case by default
• treat it as a boundary-sensitive donor because model payload licenses are separate from the code license
• the current landed HyperTwist code-side slice is not a clean-room requirement

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\coqui-ai\TTS\LICENSE.txt
• C:\Workspaces\HyperTwist\mirrors\permissive\coqui-ai\TTS\setup.py
• C:\Workspaces\HyperTwist\mirrors\permissive\coqui-ai\TTS\TTS\.models.json

Important distinction:

• the package code is MPL-2.0
• the built-in model registry mixes multiple payload licenses, including:
  • CPML
  • CC BY-NC-ND 4.0
  • Apache 2.0
  • BSD-3-Clause
  • MIT
  • MPL
• some flagship models also declare tos_required: true

Approved working posture:

• HyperTwist may use the codebase as a donor/dependency/source of architectural extraction under the MPL-2.0 code posture
• do not collapse code and model-weight licensing into one bucket
• track each chosen voice model or downloadable payload separately at implementation time
• do not misread the separate payload review requirement as a clean-room obligation for the package code
• prefer a bounded speech sidecar or service seam so the product can swap or isolate model choices later without entangling the core coaching logic
• the first bounded advanced narration slice is now landed:
  • advanced narration orchestration profile
  • normalized model/vocoder binding metadata
  • multilingual routing and speaker-selection flags
  • reference-speaker conditioning flag
  • bounded mock and HTTP voice-client seam support for the richer narration profile
  • advanced voice service-health capability exposure
• the next bounded review slice is now landed:
  • downloadable voice/model review profile
  • supported advanced voice-model review descriptors
  • advanced voice service-health review metadata
• coqui-ai/TTS remains a bounded donor, not the broad voice-platform owner
• keep downloadable voice/model review separate from the code-license judgment

rhasspy/piper

Decision date:

• 2026-04-24
• refreshed on 2026-05-13
• refreshed on 2026-05-22

Current licensing judgment:

• source code is usable for HyperTwist under MIT
• the repo is not a clean-room case
• treat it as a bounded sidecar candidate, not a foundation or broad strategic donor

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\rhasspy\piper\LICENSE.md
• C:\Workspaces\HyperTwist\mirrors\permissive\rhasspy\piper\src\python_run\piper\voices.json

Important distinction:

• the checked-in code is MIT
• the repo README says active development moved to OHF-Voice/piper1-gpl
• downloadable voice artifacts are separate from the code and should still be reviewed per selected voice/model card before being treated as default shipping assets

Approved working posture:

• HyperTwist may use the codebase and runtime shape directly as a lean local TTS sidecar under the MIT code posture
• do not over-elevate it into the broader voice strategy; its main strength is lightweight offline narration
• the first bounded local narration sidecar slice is now landed:
  • local voice-profile catalog normalization
  • narration synthesis request/result contract
  • mock and HTTP local sidecar voice-client seam
  • local voice service-health exposure
• the next bounded local review slice is now landed:
  • downloadable voice-asset review profile
  • supported local voice-asset descriptors
  • local voice service-health review metadata
• rhasspy/piper remains a bounded donor, not the broad voice-platform owner
• keep voice-asset review separate from the code-license judgment

screenpipe/screenpipe

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• mixed-license repo
• permissive core outside ee/
• enterprise-restricted subtree inside ee/
• usable as a selective donor only outside ee/

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\screenpipe\screenpipe\LICENSE.md
• C:\Workspaces\HyperTwist\mirrors\restrictive\screenpipe\screenpipe\ee\LICENSE
• C:\Workspaces\HyperTwist\mirrors\restrictive\screenpipe\screenpipe\ee\README.md
• C:\Workspaces\HyperTwist\mirrors\restrictive\screenpipe\screenpipe\Cargo.toml

Important distinction:

• top-level license file grants permissive use outside ee/
• ee/ is explicitly enterprise-licensed and production-restricted
• the Rust workspace metadata also declares permissive licensing, but the practical HyperTwist boundary still needs to exclude ee/

Approved working posture:

• treat the repo as a strategic donor with care for capture/history/replay, permissions, vault, and notification architecture
• do not treat it as a carefree blanket-permissive mirror
• do not consume ee/ under a relaxed donor posture
• keep the mirror in boundary-sensitive custody unless a narrower allowlist is created later
• current landed HyperTwist posture is the closed Phase 4R-E first-party capture-history lane, not an open donor shell
• preserve the explicit permissive-core-versus-ee/ subtree boundary in future enhancement work

ggml-org/whisper.cpp

Decision date:

• 2026-04-24
• refreshed on 2026-05-13
• implementation posture refreshed on 2026-05-21

Current licensing judgment:

• source code is usable for HyperTwist under MIT
• the repo is not a clean-room case
• treat it as a bounded speech-input sidecar rather than a foundation

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\ggml-org\whisper.cpp\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\ggml-org\whisper.cpp\include\whisper.h
• C:\Workspaces\HyperTwist\mirrors\permissive\ggml-org\whisper.cpp\examples\server\server.cpp

Important distinction:

• the code is MIT
• model files and deployment choices are still operational concerns, but there is no current code-license blocker
• the strongest current product value is bounded offline STT, especially with VAD and constrained-grammar support

Approved working posture:

• HyperTwist may use the codebase directly as the primary offline STT sidecar candidate under the MIT code posture
• keep it bounded behind a speech-input seam
• prefer command, dictation, and constrained coach-interaction use over broad “voice assistant platform” scope
• the first bounded permissive implementation slice is now landed as a speech transcript session boundary above the existing companion listening lifecycle
• the next bounded permissive implementation slice is now landed as a live microphone shell profile and shell-state boundary above the existing transcript-session seam
• the next bounded permissive implementation slice is now landed as device-permission and capture-route readiness shell posture above the existing microphone shell seam
• the next bounded first-party implementation slice is now landed as real device-permission workflow posture above the existing permission/readiness shell seam
• the next bounded permissive implementation slice is now landed as downloadable model and payload custody metadata above the existing transcript-session and shell seams
• the next bounded first-party implementation slice is now landed as provider-profile and BYOK custody metadata above the existing transcript-session, shell, and payload-custody seams
• the next bounded first-party implementation slice is now landed as provider routing and policy metadata above the existing transcript-session, shell, payload-custody, and provider-custody seams
• the next bounded first-party implementation slice is now landed as normalized usage/cost event-model metadata above the existing transcript-session, shell, payload-custody, provider-custody, and provider-routing seams
• the next bounded first-party implementation slice is now landed as provider billing settlement and invoice reconciliation shell metadata above the existing transcript-session, shell, payload-custody, provider-custody, provider-routing, usage/cost, history/export, and receipt-review seams
• the next bounded first-party implementation slice is now landed as provider settlement exception and external-portal handoff shell metadata above the existing transcript-session, shell, payload-custody, provider-custody, provider-routing, usage/cost, history/export, receipt-review, and settlement seams
• the next bounded first-party implementation slice is now landed as real device-permission workflow metadata above the existing transcript-session, shell, permission/readiness, payload-custody, provider-custody, provider-routing, usage/cost, history/export, receipt-review, settlement, and exception/handoff seams
• the next bounded first-party implementation slice is now landed as native capture-route ownership and workflow preparation/control metadata above the existing transcript-session, shell, permission/readiness, permission-workflow, payload-custody, provider-custody, provider-routing, usage/cost, history/export, receipt-review, settlement, and exception/handoff seams
• the top-level provider/session contract remains first-party HyperTwist-owned and provider-neutral; this row does not own that lane
• keep unrestricted low-level audio-device takeover, actual payment execution, provider-portal ownership, actual payload shipping, and future voice-asset review separate from the code-license judgment
• treat SYSTRAN/faster-whisper as the landed complementary Python-orchestration donor rather than widening whisper.cpp into the runtime core

SYSTRAN/faster-whisper

Decision date:

• 2026-04-24
• refreshed on 2026-05-13
• refreshed on 2026-05-21

Current licensing judgment:

• source code is usable for HyperTwist under MIT
• the repo is not a clean-room case
• treat it as a boundary-sensitive strategic donor for the Python STT lane rather than as a foundation

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\SYSTRAN\faster-whisper\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\SYSTRAN\faster-whisper\setup.py
• C:\Workspaces\HyperTwist\mirrors\permissive\SYSTRAN\faster-whisper\faster_whisper\transcribe.py
• C:\Workspaces\HyperTwist\mirrors\permissive\SYSTRAN\faster-whisper\faster_whisper\vad.py
• C:\Workspaces\HyperTwist\mirrors\permissive\SYSTRAN\faster-whisper\tests\test_transcribe.py

Important distinction:

• the code is MIT
• model artifacts still need the ordinary model-card review you would do for any selected Whisper-family checkpoint
• the strongest current product value is not generic dictation but Python-side service orchestration with batching, timestamps, VAD, and hotword support

Approved working posture:

• HyperTwist may use the codebase directly as the primary Python STT donor/service-layer candidate under the MIT code posture
• keep it bounded behind a transcription-service seam rather than letting it shape the gameplay/runtime core
• the top-level provider/session contract remains first-party HyperTwist-owned and provider-neutral; this row does not own that lane
• treat it as complementary to ggml-org/whisper.cpp: prefer whisper.cpp for harder native/runtime boundaries and faster-whisper for Python orchestration, batch transcription, richer VAD/clip orchestration, prompt hints, and rapid feature delivery
• the bounded Phase 6R-F and Phase 6R-AP implementation slices are now landed as:
  • first-party Python transcription-service orchestration profile above the existing speech session boundary
  • first-party batch-window and prompt/retrieval-hint tuning metadata above that existing speech session boundary
• keep model files, downloadable payloads, and future voice-asset review separate from the code-license judgment

cjpais/Handy

Decision date:

• 2026-05-28

Current licensing judgment:

• source code is usable for HyperTwist under MIT
• the repo is not a clean-room case
• treat it as a bounded permissive speech-adjacent adjunct rather than as the broad speech-platform owner

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\cjpais\Handy\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\cjpais\Handy\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\cjpais\Handy\src-tauri\Cargo.toml
• C:\Workspaces\HyperTwist\mirrors\permissive\cjpais\Handy\src-tauri\src\main.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\cjpais\Handy\src-tauri\src\transcription_coordinator.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\cjpais\Handy\src-tauri\src\managers\audio.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\cjpais\Handy\src-tauri\src\managers\transcription.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\cjpais\Handy\src-tauri\src\managers\model.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\cjpais\Handy\src-tauri\src\managers\history.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\cjpais\Handy\src-tauri\src\commands\transcription.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\cjpais\Handy\src-tauri\src\clipboard.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\cjpais\Handy\src-tauri\src\actions.rs
• C:\Workspaces\HyperTwist\mirrors\permissive\cjpais\Handy\src-tauri\src\llm_client.rs

Important distinction:

• the strongest HyperTwist fit is not broad assistant-platform ownership
• the strongest HyperTwist fit is not top-level provider/session ownership
• the strongest HyperTwist fit is not core native STT runtime ownership over ggml-org/whisper.cpp or Python orchestration ownership over SYSTRAN/faster-whisper
• the retained HyperTwist value is a narrower external offline dictation-shell, transcript-history, output-routing, and operator-facing OS-integration shell adjunct

Approved working posture:

• keep the mirror in permissive custody under the ordinary MIT code posture
• the bounded live Phase 6R-AJ, Phase 6R-AO, and Phase 6R-AU packets now land only:
  • external dictation-shell profile/state
  • transcript-history and retention shell behavior
  • paste, clipboard, typing, and script-oriented output routing
  • optional transcript post-process overlays above the landed speech stack
  • bounded global-hotkey lifecycle shell posture
  • bounded selected input/output device shell posture
  • bounded mute-while-recording and microphone-mode shell posture
  • bounded local model catalog review posture above the landed payload-custody seam
  • bounded payload-integrity review posture for local speech model payloads
  • bounded unload-policy review posture for local speech model payloads
• keep the top-level provider/session contract first-party and provider-neutral
• keep native speech-input runtime ownership with ggml-org/whisper.cpp
• keep Python STT orchestration ownership with SYSTRAN/faster-whisper
• keep narration and voice-output ownership with rhasspy/piper and coqui-ai/TTS
• keep these parts deferred even after Phase 6R-AU:
  • actual model download, extract, or unload execution ownership
  • broad assistant-platform scope
• keep model files, payloads, and any future downloadable asset review separate from the code-license judgment

PostHog/posthog

Decision date:

• 2026-04-24
• refreshed on 2026-05-13
• refreshed on 2026-05-13

Current licensing judgment:

• the repo is mixed-license
• content outside ee/ is available under MIT
• content under ee/ is enterprise-licensed and production-restricted
• this is not a clean-room requirement by default, but it is not a carefree permissive donor either
• treat it as the landed boundary-sensitive control-plane preserve lane through Phase 4R-D

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\PostHog\posthog\LICENSE
• C:\Workspaces\HyperTwist\mirrors\restrictive\PostHog\posthog\ee\LICENSE
• C:\Workspaces\HyperTwist\mirrors\restrictive\PostHog\posthog\frontend\src\scenes\session-recordings\utils\replayCaptureDiagnostics.ts
• C:\Workspaces\HyperTwist\mirrors\restrictive\PostHog\posthog\products\replay\skills\diagnosing-missing-recordings\references\diagnostic-signals.md
• C:\Workspaces\HyperTwist\mirrors\restrictive\PostHog\posthog\frontend\src\scenes\session-recordings\player\utils\segmenter.ts
• C:\Workspaces\HyperTwist\mirrors\restrictive\PostHog\posthog\frontend\src\scenes\session-recordings\player\utils\player-logging.ts
• C:\Workspaces\HyperTwist\mirrors\restrictive\PostHog\posthog\frontend\src\scenes\feature-flags\featureFlagReleaseConditionsLogic.ts
• C:\Workspaces\HyperTwist\mirrors\restrictive\PostHog\posthog\frontend\src\scenes\feature-flags\featureFlagScheduleEditLogic.ts
• C:\Workspaces\HyperTwist\mirrors\restrictive\PostHog\posthog\frontend\src\scenes\feature-flags\activityDescriptions.tsx
• C:\Workspaces\HyperTwist\mirrors\restrictive\PostHog\posthog\products\feature_flags\backend\models\team_feature_flag_defaults_config.py
• C:\Workspaces\HyperTwist\mirrors\restrictive\PostHog\posthog\products\early_access_features\backend\models.py
• C:\Workspaces\HyperTwist\mirrors\restrictive\PostHog\posthog\products\early_access_features\backend\api.py

Important distinction:

• the old HyperTwist board mapped this repo into the wrong lane
• it is not a vision/perception donor
• the useful value is telemetry, replay, feature-flag governance, and product/service boundary architecture
• the legal boundary is also not “whole repo MIT”; any relaxed donor use must explicitly exclude ee/
• Phase 4R-D did not copy donor ee/ files into owned Unreal source
• the landed surface is a first-party control-plane contract and runtime lane, not a broad PostHog product-shell adoption

Approved working posture:

• keep the mirror in restrictive/manual-review custody because the repo contains both MIT and enterprise-licensed code
• do not flatten it into benchmark-only status, because the replay and feature-flag lanes are genuinely useful
• do not treat it as a direct shell donor or as a vision donor
• keep the landed HyperTwist result on preserve-and-enhance footing as the first-party replay-diagnostic, feature-governance, scheduled-change, early-access, and subtree-compliance lane
• keep any relaxed donor use strictly inside clearly MIT paths and continue to exclude ee/
• preserve the explicit root-license-versus-enterprise-subtree boundary in future widening packets
• start future enhancement work from the live-lane audit, then Phase 4R-D, then this tracker, rather than from the raw mirror alone

remotion-dev/remotion

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• custom commercial two-tier license at repo level
• not a clean permissive donor
• preserve the already-landed first-party Phase 4R-F sidecar outputs
• current future-widening posture is restrictive-custody and explicit clean-room/specification work unless the lane is intentionally replaced by a first-party Unreal-native export path

Source basis:

• C:\Workspaces\HyperTwist\mirrors\restrictive\remotion-dev\remotion\LICENSE.md
• C:\Workspaces\HyperTwist\mirrors\restrictive\remotion-dev\remotion\package.json
• C:\Workspaces\HyperTwist\mirrors\restrictive\remotion-dev\remotion\packages\player\package.json
• C:\Workspaces\HyperTwist\mirrors\restrictive\remotion-dev\remotion\packages\renderer\package.json
• C:\Workspaces\HyperTwist\mirrors\restrictive\remotion-dev\remotion\packages\studio\package.json
• C:\Workspaces\HyperTwist\mirrors\restrictive\remotion-dev\remotion\packages\media-parser\package.json

Important distinction:

• the checked LICENSE.md does not use a $1M revenue threshold
• the checked LICENSE.md grants free use only for:
  • individuals
  • for-profit organizations with up to 3 employees
  • non-profits
  • evaluation use before commercial adoption
• for-profit use outside that eligibility requires a company license under the repo's current commercial terms
• some subpackages expose narrower package-level license strings, but the package split is mixed rather than uniformly permissive:
  • @remotion/studio: MIT
  • @remotion/player: SEE LICENSE IN LICENSE.md
  • @remotion/renderer: SEE LICENSE IN LICENSE.md
  • @remotion/media-parser: Remotion License https://remotion.dev/license
• the main packages HyperTwist would likely care about for export, playback, and media parsing still point back to the custom Remotion licensing posture rather than a plain MIT path

Approved working posture:

• keep it as a bounded media-export and explainer sidecar preserve lane
• do not treat it as a plain permissive donor
• do not treat it as core architecture
• if HyperTwist ever uses it directly in a commercial deployment context, confirm the exact company-license obligation for the specific package set being shipped
• do not describe this row with stale $1M language unless a later upstream license text actually reintroduces that threshold
• preserve the first-party landed result as a bounded media-export, embedded-playback, parser, explainer-studio, and package-split compliance lane
• do not treat the broader authoring shell, template ecosystem, or platform shell as landed donor value
• start future enhancement work from the live-lane audit, then Phase 4R-F, then this tracker, rather than from the raw mirror alone
• do not reopen direct donor-backed widening from the raw mirror; future widening now routes through restrictive custody and explicit clean-room/specification work, or through a first-party Unreal-native export replacement

met4citizen/TalkingHead

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under MIT
• not a clean-room case
• treat as a landed permissive preserve lane for the embodied coach and companion surface

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\met4citizen\TalkingHead\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\met4citizen\TalkingHead\package.json
• C:\Workspaces\HyperTwist\mirrors\permissive\met4citizen\TalkingHead\modules\talkinghead.mjs
• C:\Workspaces\HyperTwist\mirrors\permissive\met4citizen\TalkingHead\modules\retargeter.mjs
• C:\Workspaces\HyperTwist\mirrors\permissive\met4citizen\TalkingHead\modules\playback-worklet.js
• C:\Workspaces\HyperTwist\mirrors\permissive\met4citizen\TalkingHead\examples\azure-audio-streaming.html
• C:\Workspaces\HyperTwist\mirrors\permissive\met4citizen\TalkingHead\tests\streaming-tests.html

Important distinction:

• the code posture is cleanly MIT
• sample avatars, media, and external TTS vendor flows visible in the repo are separate provenance and deployment questions and must not be conflated with the code license
• the strongest current product value is not “talking avatar as a product,” but embodied coach presence:
  • realtime speech and lip-sync queueing
  • subtitle synchronization
  • avatarOnly embedding into an external scene/camera
  • gesture, emoji, mood, and pose orchestration
  • Mixamo-style retargeting helpers
  • low-latency streaming audio playback with underrun/queue metrics
• this lane is now landed/live in first-party Unreal surfaces through HYPERTWIST_PHASE_3R_PACKET_3R_E_TALKINGHEAD_IMPLEMENTATION_2026-05-13.md

Current implementation rule:

• preserve as a landed permissive lane
• preserve the checked MIT notice
• keep sample-avatar, media, and external voice-service provenance separate from the code-license record
• read the landed 3R-E packet and the live-lane audit before widening this lane further

Approved working posture:

• HyperTwist may use the codebase directly as a strategic donor for the embodied coach and companion lane under the MIT code posture
• keep it bounded to coach/avatar presence, narrated replay/training, and embedded companion workflows
• do not let it redefine HyperTwist into a general-purpose avatar or character product
• before shipping, separately review which sample assets, avatar packs, and external TTS integrations are actually distributable in the final product

apache/echarts

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under Apache-2.0
• not a clean-room case
• treat as a bounded analytics and reporting donor

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\apache\echarts\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\apache\echarts\NOTICE
• C:\Workspaces\HyperTwist\mirrors\permissive\apache\echarts\package.json
• C:\Workspaces\HyperTwist\mirrors\permissive\apache\echarts\src\core\echarts.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\apache\echarts\src\model\OptionManager.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\apache\echarts\src\data\DataStore.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\apache\echarts\src\component\thumbnail\ThumbnailView.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\apache\echarts\src\component\dataZoom\history.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\apache\echarts\src\component\toolbox\feature\DataView.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\apache\echarts\src\component\toolbox\feature\SaveAsImage.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\apache\echarts\ssr\client\src\index.ts

Important distinction:

• the code posture is cleanly permissive
• Apache redistribution still carries ordinary NOTICE retention expectations
• the strongest current product value is not generic charting, but bounded reporting infrastructure:
  • mature option/state management
  • multidimensional data storage
  • zoom-history and minimap/thumbnail interaction patterns
  • export and raw data-view tooling
  • accessibility support
  • SSR plus hydration for companion reporting surfaces

Approved working posture:

• HyperTwist may use the codebase directly as a bounded analytics and reporting donor under the Apache-2.0 code posture
• keep it bounded to dashboards, replay analytics, progress reporting, and exportable coaching summaries
• preserve normal Apache NOTICE obligations in redistributed builds
• do not let it redefine HyperTwist into a generic BI/dashboard product

Current implementation truth:

• Phase 3R-C is now closed and apache/echarts is a landed first-party HyperTwist analytics, reporting, export, and progress-visualization lane
• future widening for this lane should start from HYPERTWIST_PHASE_3R_PACKET_3R_C_ECHARTS_IMPLEMENTATION_2026-05-13.md, then the live-lane audit
• ecomfe/zrender and ecomfe/echarts-gl remain subordinate support lanes beneath this owner and are not separately live through 3R-C

ecomfe/zrender

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under BSD-3-Clause
• not a clean-room case
• treat as a lower-level render/dependency donor, not as a separate strategic lane

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\ecomfe\zrender\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\ecomfe\zrender\package.json
• C:\Workspaces\HyperTwist\mirrors\permissive\ecomfe\zrender\src\zrender.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\ecomfe\zrender\src\Storage.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\ecomfe\zrender\src\canvas\Painter.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\ecomfe\zrender\src\svg\Painter.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\ecomfe\zrender\src\dom\HandlerProxy.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\ecomfe\zrender\src\animation\Animator.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\ecomfe\zrender\src\graphic\Group.ts

Important distinction:

• the code posture is cleanly permissive
• the strongest current product value is not as a separate app/UI lane, but as substrate:
  • canvas and SVG painters
  • scene-graph/displayable primitives
  • event handling
  • lightweight animation
  • geometry, path, text, and image primitives
• for HyperTwist, that value is usually best realized indirectly through apache/echarts unless later work needs more direct control over custom 2D overlays or widgets

Approved working posture:

• HyperTwist may use the codebase directly under the BSD-3-Clause code posture
• keep it conceptually subordinate to the apache/echarts lane unless HyperTwist later chooses to own custom low-level 2D rendering more directly
• do not let it expand into a separate product lane by default

Current implementation truth:

• the landed apache/echarts 3R-C lane did not convert ecomfe/zrender into a separate live HyperTwist lane
• future use should stay explicitly subordinate beneath the landed apache/echarts reporting owner

ecomfe/echarts-gl

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under BSD-3-Clause
• not a clean-room case
• treat as a bounded 3D analytics and explainer donor under the apache/echarts lane

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\ecomfe\echarts-gl\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\ecomfe\echarts-gl\package.json
• C:\Workspaces\HyperTwist\mirrors\permissive\ecomfe\echarts-gl\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\ecomfe\echarts-gl\src\echarts-gl.js
• C:\Workspaces\HyperTwist\mirrors\permissive\ecomfe\echarts-gl\src\chart\common\GLViewHelper.js
• C:\Workspaces\HyperTwist\mirrors\permissive\ecomfe\echarts-gl\src\chart\surface\SurfaceView.js
• C:\Workspaces\HyperTwist\mirrors\permissive\ecomfe\echarts-gl\src\export\charts.js
• C:\Workspaces\HyperTwist\mirrors\permissive\ecomfe\echarts-gl\src\export\components.js

Important distinction:

• the code posture is cleanly permissive
• the strongest current product value is not generic WebGL ownership, but a bounded 3D analytics layer:
  • modular 3D chart exports
  • GL graph/flow views
  • grid3D, geo3D, and globe components
  • practical GL-layer mounting and zlevel coordination
  • chart-space zoom/pan-to-camera helper behavior
• that makes it useful for richer reporting and explainer surfaces, not for gameplay, puzzle rendering, or product-runtime ownership

Approved working posture:

• HyperTwist may use the codebase directly under the BSD-3-Clause code posture
• keep it subordinate to the apache/echarts lane as an optional 3D analytics and explainer layer
• do not let it expand into a simulator, puzzle-renderer, or runtime-foundation role

Current implementation truth:

• the landed apache/echarts 3R-C lane did not convert ecomfe/echarts-gl into a separate live HyperTwist lane
• future use should stay explicitly subordinate beneath the landed apache/echarts reporting owner as an optional richer analytics/explainer sidecar

pissang/claygl

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under a permissive BSD-style license text in LICENSE
• not a clean-room case
• treat as a lower-level browser 3D dependency/reference donor beneath ecomfe/echarts-gl

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\pissang\claygl\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\pissang\claygl\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\pissang\claygl\package.json
• C:\Workspaces\HyperTwist\mirrors\permissive\pissang\claygl\src\Renderer.js
• C:\Workspaces\HyperTwist\mirrors\permissive\pissang\claygl\src\application.js
• C:\Workspaces\HyperTwist\mirrors\permissive\pissang\claygl\src\Scene.js
• C:\Workspaces\HyperTwist\mirrors\permissive\pissang\claygl\src\plugin\OrbitControl.js

Important distinction:

• the checked-in license text is permissive, but it should be tracked carefully as BSD-style rather than casually over-normalized to an SPDX label without later reconciliation
• the strongest current product value is infrastructural browser-side 3D support:
  • renderer and scene graph
  • camera, light, material, geometry, and mesh primitives
  • control, picking, timeline, and compositor patterns
  • App3D shelling for compact browser 3D applications
• for HyperTwist, that value is usually best realized under the echarts-gl lane or future compact browser-side explainer widgets, not as a separate primary runtime direction

Approved working posture:

• HyperTwist may use the codebase directly under the permissive BSD-style license posture reflected in the checked-in LICENSE
• keep it subordinate to the ecomfe/echarts-gl lane as a lower-level browser 3D substrate
• do not let it expand into a simulator, puzzle-renderer, or runtime-foundation role
• keep the alternative browser 3D comparison lane deferred unless the landed three.js / react-three-fiber / xr stack later proves a real sidecar gap

pissang/clay-viewer

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under BSD-3-Clause
• not a clean-room case
• treat as a bounded browser viewer/editor sidecar donor above the pissang/claygl lane

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\pissang\clay-viewer\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\pissang\clay-viewer\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\pissang\clay-viewer\package.json
• C:\Workspaces\HyperTwist\mirrors\permissive\pissang\clay-viewer\src\Viewer.js
• C:\Workspaces\HyperTwist\mirrors\permissive\pissang\clay-viewer\src\defaultSceneConfig.js
• C:\Workspaces\HyperTwist\mirrors\permissive\pissang\clay-viewer\src\graphic\EffectCompositor.js

Important distinction:

• the code posture is cleanly permissive
• the strongest current product value is not a generic browser runtime, but a bounded viewer/editor surface:
  • picking and hotspot behavior
  • animation preview and camera control
  • environment, light, and post-effect presets
  • compact browser-side preview or explainer workflows
• the editor layer also depends on baidu/san, which is MIT, but that should remain folded as a commodity framework dependency rather than opened as a separate HyperTwist donor lane
• that makes it useful for support-plane or sidecar visualization surfaces, not for gameplay or runtime ownership

Approved working posture:

• HyperTwist may use the codebase directly under the BSD-3-Clause code posture
• keep it subordinate to the pissang/claygl lane as a viewer/editor sidecar
• do not let it expand into a gameplay, simulator, puzzle-renderer, or runtime-foundation role
• keep the optional viewer/editor comparison lane deferred unless the landed google/model-viewer plus browser-spatial stack later proves a real sidecar gap

KhronosGroup/glTF-Sample-Viewer

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under Apache-2.0
• not a clean-room case
• treat as a bounded asset-validation and standards-viewer donor

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\KhronosGroup\glTF-Sample-Viewer\LICENSE.md
• C:\Workspaces\HyperTwist\mirrors\permissive\KhronosGroup\glTF-Sample-Viewer\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\KhronosGroup\glTF-Sample-Viewer\package.json
• C:\Workspaces\HyperTwist\mirrors\permissive\KhronosGroup\glTF-Sample-Viewer\src\main.js
• C:\Workspaces\HyperTwist\mirrors\permissive\KhronosGroup\glTF-Sample-Viewer\src\logic\uimodel.js
• C:\Workspaces\HyperTwist\mirrors\permissive\KhronosGroup\glTF-Sample-Viewer\src\ui\ui.js
• C:\Workspaces\HyperTwist\mirrors\permissive\KhronosGroup\glTF-Sample-Viewer\glTF-Sample-Renderer\LICENSE.md
• C:\Workspaces\HyperTwist\mirrors\permissive\KhronosGroup\glTF-Sample-Viewer\glTF-Sample-Renderer\source\GltfView\gltf_view.js
• C:\Workspaces\HyperTwist\mirrors\permissive\KhronosGroup\glTF-Sample-Viewer\glTF-Sample-Renderer\source\ResourceLoader\resource_loader.js
• C:\Workspaces\HyperTwist\mirrors\permissive\KhronosGroup\glTF-Sample-Viewer\glTF-Sample-Renderer\source\Renderer\renderer.js

Important distinction:

• the code posture is cleanly permissive, but Apache redistribution still carries ordinary NOTICE retention expectations
• the app shell and the checked-in glTF-Sample-Renderer submodule are both part of the retained value, so HyperTwist should treat the viewer as a standards-heavy inspection stack rather than as a wrapper-only repo
• the strongest retained value is not generic product viewing, but:
  • integrated glTF validation
  • material-variant and extension-aware inspection
  • capture and camera export
  • standards-compliant preview and renderer-independent asset QA

Approved working posture:

• HyperTwist may use the codebase directly under the Apache-2.0 code posture
• preserve normal Apache NOTICE obligations in redistributed builds
• keep it bounded to asset QA, validation, preview, and inspection sidecars rather than letting it expand into gameplay, simulation, or runtime-foundation ownership

Current implementation truth:

• KhronosGroup/glTF-Sample-Viewer remains retained and source-backed
• after Phase 3R-D, it is still not separately live
• it now sits beneath the landed google/model-viewer browser viewer lane as the standards-aware asset-QA sidecar

KhronosGroup/glTF-Sample-Renderer

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under Apache-2.0
• not a clean-room case
• treat as a lower-level official glTF renderer/reference donor beneath the KhronosGroup/glTF-Sample-Viewer lane

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\KhronosGroup\glTF-Sample-Viewer\glTF-Sample-Renderer\LICENSE.md
• C:\Workspaces\HyperTwist\mirrors\permissive\KhronosGroup\glTF-Sample-Viewer\glTF-Sample-Renderer\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\KhronosGroup\glTF-Sample-Viewer\glTF-Sample-Renderer\package.json
• C:\Workspaces\HyperTwist\mirrors\permissive\KhronosGroup\glTF-Sample-Viewer\glTF-Sample-Renderer\source\GltfView\gltf_view.js
• C:\Workspaces\HyperTwist\mirrors\permissive\KhronosGroup\glTF-Sample-Viewer\glTF-Sample-Renderer\source\GltfState\gltf_state.js
• C:\Workspaces\HyperTwist\mirrors\permissive\KhronosGroup\glTF-Sample-Viewer\glTF-Sample-Renderer\source\ResourceLoader\resource_loader.js
• C:\Workspaces\HyperTwist\mirrors\permissive\KhronosGroup\glTF-Sample-Viewer\glTF-Sample-Renderer\source\Renderer\renderer.js
• C:\Workspaces\HyperTwist\mirrors\permissive\KhronosGroup\glTF-Sample-Viewer\glTF-Sample-Renderer\source\gltf\user_camera.js

Important distinction:

• the code posture is cleanly permissive, but Apache redistribution still carries ordinary NOTICE retention expectations
• this repo is the actual renderer/runtime beneath the sample viewer rather than a throwaway submodule:
  • GltfView manages context and frame rendering
  • GltfState models view content and render parameters
  • ResourceLoader handles standards-aware resource loading and decoding
  • UserCamera and related state types provide practical view-control patterns
• for HyperTwist, that value is mostly infrastructural and standards-focused, not end-user product-facing

Approved working posture:

• HyperTwist may use the codebase directly under the Apache-2.0 code posture
• preserve normal Apache NOTICE obligations in redistributed builds
• keep it subordinate to the KhronosGroup/glTF-Sample-Viewer lane as a lower-level renderer substrate for asset QA and inspection tooling rather than letting it expand into gameplay, simulation, or runtime-foundation ownership

Current implementation truth:

• KhronosGroup/glTF-Sample-Renderer remains retained and source-backed
• after Phase 3R-D, it is still not separately live
• it now sits beneath the landed google/model-viewer asset-QA lane as the lower-level reference renderer substrate

google/model-viewer

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under Apache-2.0
• not a clean-room case
• treat as a bounded browser 3D presentation, inspection, and editor donor

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\package.json
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\model-viewer\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\model-viewer\src\model-viewer.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\render-fidelity-tools\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\space-opera\package.json
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\space-opera\src\app.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\space-opera\src\reducers.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\space-opera\src\components\inspector\inspector.ts

Important distinction:

• the code posture is cleanly permissive, but Apache redistribution still carries ordinary NOTICE retention expectations
• this repo is not just the <model-viewer> component:
  • the core web component exposes polished browser presentation behavior via mixin composition
  • render-fidelity-tools carries real quality-comparison discipline
  • space-opera is a real client-side GLB editor and inspector surface
• for HyperTwist, the strongest retained value is polished web presentation and editor/inspection behavior, not browser-first runtime ownership

Approved working posture:

• HyperTwist may use the codebase directly under the Apache-2.0 code posture
• preserve normal Apache NOTICE obligations in redistributed builds
• keep it bounded to embeddable web presentation, inspection, editor, and render-fidelity lanes rather than letting it expand into gameplay, simulation, or runtime-foundation ownership
• keep the space-opera, render-fidelity-tools, model-viewer-effects, modelviewer.dev, and shared-assets package rows normalized under the parent google/model-viewer git-root authority in generated legal-evidence passes; they remain package-specific authority slices rather than separate standalone mirror roots

Current implementation truth:

• google/model-viewer is now landed through Phase 3R-D
• it is now a verified live permissive lane in checked UnrealHyperTwist surfaces
• the live first-party lane owns browser presentation, compact editor, and standards-aware asset-QA contracts

google/model-viewer/packages/space-opera

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• package code is usable for HyperTwist under Apache-2.0
• not a clean-room case
• treat as a bounded browser editor and inspection donor beneath the google/model-viewer lane

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\space-opera\package.json
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\space-opera\src\app.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\space-opera\src\reducers.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\space-opera\src\components\inspector\inspector.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\space-opera\src\components\model_viewer_snippet\model_viewer_snippet.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\space-opera\src\components\hotspot_panel\hotspot_panel.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\space-opera\src\components\camera_settings\camera_settings.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\space-opera\src\components\model_viewer_preview\model_viewer_preview.ts

Important distinction:

• the code posture is cleanly permissive, but Apache redistribution still carries ordinary NOTICE retention expectations
• this package is not editor demo glue:
  • it has a real reducer/state shell
  • it has productized hotspot, camera, preview, snippet/export, and inspection surfaces
  • it is intentionally described by upstream as an interactive client-side UI for editing GLBs and <model-viewer> attributes
• for HyperTwist, the strongest retained value is compact browser-side editor and inspection UX, not standalone product ownership

Approved working posture:

• HyperTwist may use the package directly under the Apache-2.0 code posture
• preserve normal Apache NOTICE obligations in redistributed builds
• keep it subordinate to the google/model-viewer lane as a bounded editor and inspection package rather than letting it expand into gameplay, simulation, or runtime-foundation ownership

google/model-viewer/packages/render-fidelity-tools

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• package code is usable for HyperTwist under Apache-2.0
• not a clean-room case
• treat as a bounded fidelity oracle and QA harness donor beneath the google/model-viewer lane

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\render-fidelity-tools\package.json
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\render-fidelity-tools\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\render-fidelity-tools\src\workflows\test-fidelity.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\render-fidelity-tools\src\workflows\render-goldens.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\render-fidelity-tools\src\components\renderer-harness.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\render-fidelity-tools\src\image-comparison-worker.ts

Important distinction:

• the code posture is cleanly permissive, but Apache redistribution still carries ordinary NOTICE retention expectations
• this package is not passive test glue:
  • it has explicit scenario and renderer harnessing
  • it has golden-image generation workflows
  • it has artifact creation and result reporting
  • it has off-thread image comparison and delta visualization
• for HyperTwist, the strongest retained value is browser-side visual QA and oracle discipline, not standalone product ownership

Approved working posture:

• HyperTwist may use the package directly under the Apache-2.0 code posture
• preserve normal Apache NOTICE obligations in redistributed builds
• keep it subordinate to the google/model-viewer lane as a bounded fidelity oracle and QA harness package rather than letting it expand into gameplay, simulation, or runtime-foundation ownership

google/model-viewer/packages/model-viewer-effects

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• package code is usable for HyperTwist under Apache-2.0
• not a clean-room case
• treat as a bounded browser post-processing and emphasis donor beneath the google/model-viewer lane

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\model-viewer-effects\package.json
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\model-viewer-effects\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\model-viewer-effects\src\effect-composer.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\model-viewer-effects\src\model-viewer-effects.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\model-viewer-effects\src\effects\outline.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\model-viewer-effects\src\effects\ssao.ts

Important distinction:

• the code posture is cleanly permissive, but Apache redistribution still carries ordinary NOTICE retention expectations
• this package is not a cosmetic demo addon:
  • it has a real effect-composer integration layer between <model-viewer>, scene/camera state, and postprocessing
  • it exposes a real custom-element surface for multiple effects
  • it carries practical emphasis and quality-shaping behaviors such as outline/selective emphasis and SSAO
• for HyperTwist, the strongest retained value is browser-side highlight, emphasis, and explainer presentation patterns, not standalone product ownership

Approved working posture:

• HyperTwist may use the package directly under the Apache-2.0 code posture
• preserve normal Apache NOTICE obligations in redistributed builds
• keep it subordinate to the google/model-viewer lane as a bounded post-processing and emphasis package rather than letting it expand into gameplay, simulation, or runtime-foundation ownership

google/model-viewer/packages/modelviewer.dev

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• package code is usable for HyperTwist under Apache-2.0
• not a clean-room case
• treat as a bounded docs/demo donor beneath the google/model-viewer lane

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\modelviewer.dev\package.json
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\modelviewer.dev\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\modelviewer.dev\src\components\example-snippet.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\modelviewer.dev\src\docs-and-examples\create-html.ts
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\modelviewer.dev\src\docs-and-examples\sidebar.ts

Important distinction:

• the code posture is cleanly permissive, but Apache redistribution still carries ordinary NOTICE retention expectations
• this package is not just static docs:
  • it is the live documentation and examples site package for the model-viewer lane
  • it carries a strong single-source snippet-to-live-demo pattern in example-snippet.ts
  • it carries real docs navigation, sidebar, and HTML-generation logic
• for HyperTwist, the strongest retained value is interactive documentation and runnable example infrastructure, not standalone product ownership

Approved working posture:

• HyperTwist may use the package directly under the Apache-2.0 code posture
• preserve normal Apache NOTICE obligations in redistributed builds
• keep it subordinate to the google/model-viewer lane as a bounded docs/demo package rather than letting it expand into gameplay, simulation, or runtime-foundation ownership

google/model-viewer/packages/shared-assets

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• the package container is shipped under Apache-2.0
• this is not a clean-room case
• treat as a boundary-sensitive sample-asset and test-fixture pack beneath the google/model-viewer lane

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\shared-assets\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\shared-assets\ATTRIBUTIONS.md
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\shared-assets\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer\packages\shared-assets\scripts\fetch-khronos-gltf-samples.sh

Important distinction:

• the package container license is Apache-2.0, but the actual payloads are mixed third-party assets with their own attribution and usage terms
• ATTRIBUTIONS.md explicitly calls out multiple asset-level postures such as:
  • CC-BY
  • CC0
  • CC-BY-NC
  • CC-BY-NC-SA
  • Smithsonian usage conditions
• this package is therefore not a normal permissive code donor and not a blanket shippable asset bundle
• for HyperTwist, the strongest retained value is local fixture and sample coverage:
  • viewer/demo assets
  • environment-lighting tests
  • docs/examples payloads
  • visual QA samples

Approved working posture:

• HyperTwist may retain the package for local fixtures, demos, QA, and documentation examples
• preserve Apache NOTICE expectations for the package container where applicable
• review each asset individually before shipping anything derived from this pack in product builds
• keep it subordinate to the google/model-viewer lane as a mixed-provenance sample-asset package rather than treating it as a normal donor or shippable asset source
• Phase 4R-C is now closed for this row
• the landed first-party result is an explicit shared-assets allowlist, provenance-boundary, and fixture-refresh lane rather than a blanket asset import
• the current shipping posture is:
  • explicit CC0 ship-eligible QA fixtures
  • explicit notice-bound review fixtures
  • explicit Smithsonian review-only fixtures
  • explicit local-only restricted fixtures
  • explicit contributor-noted geometry smoke-test fixtures that still require per-asset review before shipping

mrdoob/three.js

Decision date:

• 2026-04-24
• refreshed on 2026-05-13
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under MIT
• not a clean-room case
• treat as the landed permissive browser 3D substrate preserve lane through Phase 3R-F

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\mrdoob\three.js\package.json
• C:\Workspaces\HyperTwist\mirrors\permissive\mrdoob\three.js\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\mrdoob\three.js\src\Three.Core.js
• C:\Workspaces\HyperTwist\mirrors\permissive\mrdoob\three.js\src\renderers\WebGLRenderer.js
• C:\Workspaces\HyperTwist\mirrors\permissive\mrdoob\three.js\src\renderers\webxr\WebXRManager.js
• C:\Workspaces\HyperTwist\mirrors\permissive\mrdoob\three.js\editor\index.html

Important distinction:

• the code posture is cleanly permissive under MIT
• this repo is not just a small rendering helper:
  • it exports the broad renderer, scene, camera, math, materials, loaders, textures, animation, audio, and helper surface that much of the browser-side ecosystem depends on
  • it carries real WebXR management and controller-handling infrastructure
  • it carries a real editor shell and a large addons ecosystem
• for HyperTwist, the strongest retained value is as a shared substrate beneath browser-side viewers, docs, coach-avatar surfaces, and support tools, not as a replacement for the Unreal-first runtime stance

Approved working posture:

• HyperTwist may use the repo directly under the MIT code posture
• preserve it as the landed first-party browser 3D substrate lane
• future widening should start from the live-lane audit, then HYPERTWIST_PHASE_3R_PACKET_3R_F_BROWSER_SPATIAL_SUPPORT_IMPLEMENTATION_2026-05-13.md, then this file
• keep it beneath the higher-level browser packages and do not let it get mistaken for HyperTwist's owned runtime foundation

pmndrs/postprocessing

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under Zlib
• not a clean-room case
• treat as a bounded browser post-processing substrate beneath mrdoob/three.js

Source basis:

• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\postprocessing\package.json
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\postprocessing\README.md
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\postprocessing\LICENSE.md
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\postprocessing\src\core\EffectComposer.js
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\postprocessing\src\passes\EffectPass.js
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\postprocessing\src\effects\OutlineEffect.js
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\postprocessing\src\effects\SSAOEffect.js

Important distinction:

• the code posture is cleanly permissive under Zlib
• this repo is not just effect-demo glue:
  • it carries real EffectComposer infrastructure for pass orchestration
  • it carries EffectPass integration that merges effect workflows efficiently
  • it carries practical outline/selective emphasis and SSAO behavior directly relevant to browser-side explainer and inspection surfaces
• for HyperTwist, the strongest retained value is browser-side post-effect infrastructure beneath viewer and explainer lanes, not standalone product ownership

Approved working posture:

• HyperTwist may use the repo directly under the Zlib code posture
• treat it as the browser post-effect substrate beneath mrdoob/three.js
• keep it beneath higher-level browser viewer/editor packages and do not let it get mistaken for a gameplay, simulation, or runtime-foundation lane

pmndrs/react-postprocessing

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under MIT
• not a clean-room case
• treat as a bounded React wrapper donor beneath pmndrs/postprocessing and mrdoob/three.js

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\pmndrs\react-postprocessing\package.json
• C:\Workspaces\HyperTwist\mirrors\permissive\pmndrs\react-postprocessing\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\pmndrs\react-postprocessing\src\EffectComposer.tsx
• C:\Workspaces\HyperTwist\mirrors\permissive\pmndrs\react-postprocessing\src\Selection.tsx
• C:\Workspaces\HyperTwist\mirrors\permissive\pmndrs\react-postprocessing\LICENSE

Important distinction:

• the code posture is cleanly permissive under MIT
• this repo is not the underlying post-effect substrate:
  • it wraps postprocessing for React and @react-three/fiber
  • it provides declarative React-side EffectComposer orchestration
  • it provides practical selection/highlight plumbing for outline-style workflows
• for HyperTwist, the strongest retained value is ergonomic React-side integration for browser support surfaces, not standalone product ownership

Approved working posture:

• HyperTwist may use the repo directly under the MIT code posture
• keep it beneath pmndrs/postprocessing and mrdoob/three.js
• use it only where React browser tooling is already the right fit, and do not let it get mistaken for a gameplay, simulation, or runtime-foundation lane

pmndrs/react-three-fiber

Decision date:

• 2026-04-24
• refreshed on 2026-05-13
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under MIT
• not a clean-room case
• treat as the landed permissive React-side browser renderer preserve lane through Phase 3R-F

Source basis:

• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-three-fiber\package.json
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-three-fiber\readme.md
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-three-fiber\packages\fiber\package.json
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-three-fiber\packages\fiber\src\web\Canvas.tsx
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-three-fiber\packages\fiber\src\core\renderer.tsx
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-three-fiber\packages\fiber\src\core\events.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-three-fiber\packages\fiber\src\core\hooks.tsx
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-three-fiber\packages\fiber\src\native.tsx

Important distinction:

• the code posture is cleanly permissive under MIT
• this repo is not just JSX sugar:
  • it carries the actual React renderer/runtime layer over three.js
  • it provides Canvas and createRoot runtime shelling
  • it provides real event, hook, loader, and store/reconciler infrastructure
  • it also carries a native path, not just browser rendering
• for HyperTwist, the strongest retained value is as the React-side 3D renderer substrate for browser support surfaces, not as product ownership and not as a replacement for the Unreal-first runtime stance

Approved working posture:

• HyperTwist may use the repo directly under the MIT code posture
• preserve it as the landed first-party React-side browser renderer lane
• future widening should start from the live-lane audit, then HYPERTWIST_PHASE_3R_PACKET_3R_F_BROWSER_SPATIAL_SUPPORT_IMPLEMENTATION_2026-05-13.md, then this file
• keep it beneath the higher-level browser-side support packages and do not let it get mistaken for a gameplay, simulation, or runtime-foundation lane

pmndrs/drei

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under MIT
• not a clean-room case
• treat as a bounded browser helper and abstraction donor above pmndrs/react-three-fiber

Source basis:

• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\drei\package.json
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\drei\README.md
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\drei\src\core\TransformControls.tsx
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\drei\src\web\Html.tsx
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\drei\src\web\View.tsx
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\drei\src\core\Gltf.tsx
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\drei\src\core\Environment.tsx

Important distinction:

• the code posture is cleanly permissive under MIT
• this repo is not just generic convenience sugar:
  • it carries real editor/control abstractions
  • it carries DOM-in-3D overlay behavior
  • it carries split-view and scissored multi-view composition
  • it carries practical GLTF and environment/staging wrappers
• for HyperTwist, the strongest retained value is browser-side helper leverage above react-three-fiber, not product ownership and not a replacement for the Unreal-first runtime stance

Approved working posture:

• HyperTwist may use the repo directly under the MIT code posture
• treat it as the high-leverage helper and abstraction layer above pmndrs/react-three-fiber
• keep it beneath the browser-side product lanes and do not let it get mistaken for a gameplay, simulation, or runtime-foundation lane

pmndrs/xr

Decision date:

• 2026-04-24
• refreshed on 2026-05-13
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under MIT
• not a clean-room case
• treat as the landed permissive browser XR session and immersive interaction preserve lane through Phase 3R-F

Source basis:

• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\xr\package.json
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\xr\README.md
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\xr\packages\xr\src\store.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\xr\packages\react\xr\src\xr.tsx
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\xr\packages\react\xr\src\dom-overlay.tsx
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\xr\packages\react\xr\src\controller-locomotion.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\xr\packages\pointer-events\src\index.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\xr\packages\react\handle\src\component.tsx

Important distinction:

• the code posture is cleanly permissive under MIT
• this repo is not just a thin XR wrapper:
  • it carries a real XR session and state-store layer
  • it carries React and non-React runtime bridges
  • it carries DOM overlay support for handheld AR
  • it carries XR pointer-event and manipulation infrastructure
• for HyperTwist, the strongest retained value is browser XR interaction and immersive support-plane behavior, not product ownership and not a replacement for the Unreal-first runtime stance

Approved working posture:

• HyperTwist may use the repo directly under the MIT code posture
• preserve it as the landed first-party browser XR session and immersive interaction lane
• future widening should start from the live-lane audit, then HYPERTWIST_PHASE_3R_PACKET_3R_F_BROWSER_SPATIAL_SUPPORT_IMPLEMENTATION_2026-05-13.md, then this file
• keep it in the browser XR and immersive-support lane, and do not let it get mistaken for a gameplay, simulation, or runtime-foundation lane

pmndrs/uikit

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under MIT
• not a clean-room case
• treat as a strategic donor for browser spatial UI and 3D interface substrate

Source basis:

• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\uikit\README.md
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\uikit\LICENSE
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\uikit\packages\react\package.json
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\uikit\packages\react\src\index.tsx
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\uikit\packages\react\src\build.tsx
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\uikit\packages\uikit\README.md
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\uikit\packages\uikit\src\components\fullscreen.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\uikit\packages\uikit\src\components\container.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\uikit\packages\uikit\THIRD_PARTY_LICENSES

Important distinction:

• the code posture is cleanly permissive under MIT
• this repo is not just styling:
  • it carries a real yoga/flex spatial layout runtime
  • it carries fullscreen camera-attached UI behavior
  • it carries clipping, scrolling, panel, text, and input infrastructure
  • it carries a real React bridge into react-three-fiber
• for HyperTwist, the strongest retained value is browser-side spatial UI and immersive support-plane composition, not product ownership and not a replacement for the Unreal-first runtime stance

Approved working posture:

• HyperTwist may use the repo directly under the MIT code posture
• treat it as the browser spatial UI layer beside pmndrs/xr
• preserve ordinary MIT notices and keep the bundled third-party notice context visible in the implementation record
• do not let it get mistaken for a gameplay, simulation, or runtime-foundation lane

pmndrs/three-stdlib

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under MIT
• not a clean-room case
• treat as a reference and dependency donor for shared browser-side three.js utilities

Source basis:

• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\three-stdlib\package.json
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\three-stdlib\README.md
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\three-stdlib\src\index.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\three-stdlib\src\controls\TransformControls.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\three-stdlib\src\webxr\XRControllerModelFactory.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\three-stdlib\src\postprocessing\EffectComposer.ts

Important distinction:

• the code posture is cleanly permissive under MIT
• this repo is not a product lane:
  • it is a maintained standalone packaging of three.js examples/helpers
  • it provides a shared dependency surface for controls, loaders, WebXR helpers, postprocessing helpers, renderers, and exporters
• for HyperTwist, the strongest retained value is as infrastructure beneath higher-level browser-side repos, not product ownership and not a replacement for the Unreal-first runtime stance

Approved working posture:

• HyperTwist may use the repo directly under the MIT code posture
• treat it as a shared utility substrate beneath mrdoob/three.js and higher-level browser-side lanes such as drei and xr
• do not let it get mistaken for a gameplay, simulation, or runtime-foundation lane

pmndrs/maath

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under MIT
• not a clean-room case
• treat as a reference and dependency donor for browser-side math helpers

Source basis:

• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\maath\package.json
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\maath\README.md
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\maath\packages\maath\src\index.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\maath\packages\maath\src\easing.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\maath\packages\maath\src\geometry.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\maath\packages\maath\src\random\index.ts

Important distinction:

• the code posture is cleanly permissive under MIT
• this repo is not a product lane:
  • it is a focused collection of math, motion, and sampling helpers
  • its strongest retained value is easing/damping and related browser-side polish utilities
• for HyperTwist, the strongest retained value is as a narrow convenience layer beneath higher-level browser-side repos, not product ownership and not a replacement for the Unreal-first runtime stance

Approved working posture:

• HyperTwist may use the repo directly under the MIT code posture
• treat it as a browser-side math-helper substrate beneath mrdoob/three.js, pmndrs/three-stdlib, and higher-level browser-side lanes
• do not let it get mistaken for a gameplay, simulation, or runtime-foundation lane

pmndrs/zustand

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under MIT
• not a clean-room case
• treat as a commodity strategic dependency for browser-side state management

Source basis:

• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\zustand\package.json
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\zustand\README.md
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\zustand\src\vanilla.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\zustand\src\react.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\zustand\src\traditional.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\zustand\src\middleware.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\zustand\src\middleware\persist.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\zustand\src\middleware\devtools.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\zustand\src\middleware\subscribeWithSelector.ts

Important distinction:

• the code posture is cleanly permissive under MIT
• this repo is not a product lane:
  • it is a focused browser-side store substrate
  • its strongest retained value is the vanilla store kernel, selector subscriptions, persistence/hydration, and devtools plumbing
• for HyperTwist, the strongest retained value is as shared state infrastructure beneath browser-side viewers, XR, spatial UI, and support-plane tools, not product ownership and not a replacement for the Unreal-first runtime stance

Approved working posture:

• HyperTwist may use the repo directly under the MIT code posture
• treat it as a browser-side state-management substrate beneath React, XR, and spatial UI browser lanes
• do not let it get mistaken for a gameplay, simulation, or runtime-foundation lane

pmndrs/leva

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under MIT
• not a clean-room case
• treat as a bounded donor for browser-side control panels and headless parameter UIs

Source basis:

• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\leva\package.json
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\leva\README.md
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\leva\packages\leva\src\store.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\leva\packages\leva\src\useControls.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\leva\packages\leva\src\components\Leva\LevaPanel.tsx
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\leva\packages\leva\src\plugin.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\leva\packages\leva\src\headless\README.md

Important distinction:

• the code posture is cleanly permissive under MIT
• this repo is not a product lane:
  • it is a parameter-control runtime with a serious headless/custom-surface path
  • its strongest retained value is schema-driven controls, multi-panel stores, plugin/custom-input support, and headless XR/custom UI integration
• for HyperTwist, the strongest retained value is as bounded browser-side control and authoring infrastructure beneath higher-level browser tools and immersive support surfaces, not product ownership and not a replacement for the Unreal-first runtime stance

Approved working posture:

• HyperTwist may use the repo directly under the MIT code posture
• treat it as a bounded browser-side control-panel and parameter-UI donor beside pmndrs/zustand, pmndrs/xr, and pmndrs/uikit
• do not let it get mistaken for a gameplay, simulation, or runtime-foundation lane

pmndrs/use-gesture

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under MIT
• not a clean-room case
• treat as a commodity strategic dependency for browser-side gesture and richer pointer-input behavior

Source basis:

• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\use-gesture\package.json
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\use-gesture\README.md
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\use-gesture\packages\core\src\Controller.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\use-gesture\packages\core\src\engines\DragEngine.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\use-gesture\packages\react\src\createUseGesture.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\use-gesture\packages\vanilla\src\Gesture.ts

Important distinction:

• the code posture is cleanly permissive under MIT
• this repo is not a product lane:
  • it is a gesture/input engine with React and vanilla bindings
  • its strongest retained value is controller/engine orchestration, richer pointer handling, and browser-side gesture behavior
• for HyperTwist, the strongest retained value is as shared browser-side interaction plumbing beneath viewers, support tools, and spatial/browser interfaces, not product ownership and not a replacement for the Unreal-first runtime stance

Approved working posture:

• HyperTwist may use the repo directly under the MIT code posture
• treat it as a browser-side gesture/input substrate beside pmndrs/zustand, pmndrs/leva, pmndrs/xr, and pmndrs/uikit
• do not let it get mistaken for a gameplay, simulation, or runtime-foundation lane

pmndrs/react-spring

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• repo code is usable for HyperTwist under MIT
• not a clean-room case
• treat as a commodity strategic dependency for browser-side spring motion and animation behavior

Source basis:

• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\package.json
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\README.md
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\core\src\Controller.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\core\src\SpringValue.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\react-spring\src\index.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\rafz\src\index.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\parallax\src\index.tsx

Important distinction:

• the code posture is cleanly permissive under MIT
• this repo is not a product lane:
  • it is a spring-motion runtime with a real scheduling layer and multiple target bindings
  • its strongest retained value is controller/runtime motion behavior, rafz scheduling discipline, and layered browser-side motion patterns
• for HyperTwist, the strongest retained value is as shared browser-side motion infrastructure beneath viewers, support tools, and spatial/browser interaction layers, not product ownership and not a replacement for the Unreal-first runtime stance

Approved working posture:

• HyperTwist may use the repo directly under the MIT code posture
• treat it as a browser-side motion substrate beside pmndrs/use-gesture, pmndrs/zustand, pmndrs/xr, and pmndrs/uikit
• do not let it get mistaken for a gameplay, simulation, or runtime-foundation lane
• keep the core, shared, types, parallax, rafz, and animated package rows normalized under the parent pmndrs/react-spring git-root authority in generated legal-evidence passes; they remain package-specific authority slices rather than separate standalone mirror roots

@react-spring/core

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• package code is usable for HyperTwist under MIT
• not a clean-room case
• treat as a commodity strategic dependency for platform-agnostic spring-runtime behavior beneath pmndrs/react-spring

Source basis:

• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\core\package.json
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\core\README.md
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\core\src\Controller.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\core\src\SpringValue.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\core\src\hooks\useSprings.ts

Important distinction:

• the package posture is cleanly permissive under MIT
• this package is not internal noise:
  • it contains the real controller orchestration and queued-update lifecycle
  • it contains the real SpringValue motion engine
  • it contains hook-driven multi-spring coordination and commit-phase flush behavior
  • it is a distinct published package beneath the broader react-spring lane
• for HyperTwist, the strongest retained value is lower-level motion runtime behavior beneath browser-side support surfaces, not standalone product ownership

Approved working posture:

• HyperTwist may use the package directly under the MIT code posture
• treat it as a platform-agnostic spring-runtime core package beneath pmndrs/react-spring
• do not let it get mistaken for a gameplay, simulation, or runtime-foundation lane

@react-spring/shared

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• package code is usable for HyperTwist under MIT
• not a clean-room case
• treat as a reference and dependency donor for lower-level browser-side motion-utility behavior beneath pmndrs/react-spring

Source basis:

• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\shared\package.json
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\shared\README.md
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\shared\src\index.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\shared\src\globals.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\shared\src\FrameLoop.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\shared\src\createInterpolator.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\shared\src\fluids.ts

Important distinction:

• the package posture is cleanly permissive under MIT
• this package is not just random helpers:
  • it contains globals configuration seams for interpolation, RAF behavior, batching, and frame-loop policy
  • it contains a priority-aware frame loop above rafz
  • it contains the fluid-value and observer substrate used across animated values and dependency tracking
  • it contains interpolation helpers and shared exports used across the motion stack
  • it is a distinct published package beneath the broader react-spring lane
• for HyperTwist, the strongest retained value is lower-level motion infrastructure beneath browser-side support surfaces, not standalone product ownership

Approved working posture:

• HyperTwist may use the package directly under the MIT code posture
• treat it as a lower-level motion-utility and fluid-observer package beneath pmndrs/react-spring
• do not let it get mistaken for a gameplay, simulation, or runtime-foundation lane

@react-spring/types

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• package code is usable for HyperTwist under MIT
• not a clean-room case
• treat as a reference and dependency donor for narrow type-contract and package-design behavior beneath pmndrs/react-spring

Source basis:

• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\types\package.json
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\types\src\index.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\types\src\animated.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\types\src\interpolation.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\types\src\utils.ts

Important distinction:

• the package posture is cleanly permissive under MIT
• this package is intentionally narrow:
  • it contains shared Animatable constraints
  • it contains interpolation config and factory contracts
  • it contains generic utility types used across the motion stack
  • it is a distinct published package beneath the broader react-spring lane
• for HyperTwist, the strongest retained value is package-contract clarity rather than runtime or product behavior

Approved working posture:

• HyperTwist may use the package directly under the MIT code posture
• treat it as a narrow type-contract and package-design substrate beneath pmndrs/react-spring
• do not let it get mistaken for a gameplay, simulation, or runtime-foundation lane

eslint-config-react-spring

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• package code is usable under MIT
• private tooling package
• folded into the broader pmndrs/react-spring repo context rather than tracked as a separate HyperTwist lane

Source basis:

• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\eslint-config\package.json
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\eslint-config\index.js

Important distinction:

• this package is only repo-local ESLint configuration
• it has no runtime behavior, no product behavior, and no clean-room relevance
• its retained value is ordinary TypeScript/React lint policy, not architectural leverage

Approved working posture:

• do not open a separate dossier lane for it
• do not add it as a separate repo/package track in the active HyperTwist architecture ledgers
• treat it as folded commodity tooling beneath pmndrs/react-spring

@react-spring/parallax

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• package code is usable for HyperTwist under MIT
• not a clean-room case
• treat as a bounded layered-motion and explainer sidecar beneath pmndrs/react-spring

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\pmndrs\react-spring\packages\parallax\package.json
• C:\Workspaces\HyperTwist\mirrors\permissive\pmndrs\react-spring\packages\parallax\src\index.tsx
• C:\Workspaces\HyperTwist\mirrors\permissive\pmndrs\react-spring\packages\parallax\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\pmndrs\react-spring\packages\parallax\test\README.md

Important distinction:

• the package posture is cleanly permissive under MIT
• this package is not demo glue:
  • it contains a real layered page-space and sticky-layer runtime
  • it has controller-backed scroll animation and imperative navigation
  • it is a distinct published package beneath the broader react-spring lane
• for HyperTwist, the strongest retained value is browser-side explainer and narrative motion, not standalone product ownership

Approved working posture:

• HyperTwist may use the package directly under the MIT code posture
• treat it as a bounded layered-motion and explainer package beneath pmndrs/react-spring
• do not let it get mistaken for a gameplay, simulation, or runtime-foundation lane

@react-spring/rafz

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• package code is usable for HyperTwist under MIT
• not a clean-room case
• treat as a reference and dependency donor for browser-side frame-loop and scheduling behavior beneath pmndrs/react-spring

Source basis:

• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\rafz\package.json
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\rafz\README.md
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\rafz\src\index.ts

Important distinction:

• the package posture is cleanly permissive under MIT
• this package is not internal noise:
  • it contains a real phased queue and frame-loop runtime
  • it exposes timeout, throttle, batching, and demand-driven scheduling semantics
  • it is a distinct published package beneath the broader react-spring lane
• for HyperTwist, the strongest retained value is browser-side scheduling discipline beneath motion and interaction surfaces, not standalone product ownership

Approved working posture:

• HyperTwist may use the package directly under the MIT code posture
• treat it as a bounded frame-loop and scheduling utility package beneath pmndrs/react-spring
• do not let it get mistaken for a gameplay, simulation, or runtime-foundation lane

@react-spring/animated

Decision date:

• 2026-04-24
• refreshed on 2026-05-13

Current licensing judgment:

• package code is usable for HyperTwist under MIT
• not a clean-room case
• treat as a bounded donor for browser-side animatable-component and animated-props behavior beneath pmndrs/react-spring

Source basis:

• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\animated\package.json
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\animated\README.md
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\animated\src\createHost.ts
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\animated\src\withAnimated.tsx
• C:\Workspaces\HyperTwist\cache\repo-intake\pmndrs\react-spring\packages\animated\src\Animated.ts

Important distinction:

• the package posture is cleanly permissive under MIT
• this package is not internal noise:
  • it contains real host-creation logic for animated component families
  • it wraps component targets with dependency observation over animated props
  • it decides between native updates and rerender fallback when animated updates apply
  • it is a distinct published package beneath the broader react-spring lane
• for HyperTwist, the strongest retained value is lower-level animated-component plumbing beneath browser-side motion and support surfaces, not standalone product ownership

Approved working posture:

• HyperTwist may use the package directly under the MIT code posture
• treat it as a bounded animatable-component and animated-props substrate beneath pmndrs/react-spring
• do not let it get mistaken for a gameplay, simulation, or runtime-foundation lane

roice3/Magic120Cell

Decision date:

• 2026-05-01

Current licensing judgment:

• usable for HyperTwist
• direct donor candidate
• standard MIT
• the first narrower bounded implementation slice is now landed in current code:
  • dedicated 120-cell family runtime-profile contract
  • family persistence and twist-history boundary
  • symmetry-aware focus view-profile contract
  • direct-donor attribution boundary
• the row remains only partially incorporated; host-shell ownership, broad renderer ownership, generic topology ownership, and broad interaction-shell widening stay deferred

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\roice3\Magic120Cell\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\roice3\Magic120Cell\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\roice3\Magic120Cell\Magic120Cell\workFiles\magic120Cell.cpp
• C:\Workspaces\HyperTwist\mirrors\permissive\roice3\Magic120Cell\Magic120Cell\workFiles\loader.cpp
• C:\Workspaces\HyperTwist\mirrors\permissive\roice3\Magic120Cell\Magic120Cell\workFiles\settings.cpp
• C:\Workspaces\HyperTwist\mirrors\permissive\roice3\Magic120Cell\Magic120Cell\workFiles\settings.h
• C:\Workspaces\HyperTwist\mirrors\permissive\roice3\Magic120Cell\geometryLib\puzzle\twist.h

Practical obligations:

• preserve the upstream MIT license text
• preserve the upstream copyright notice:
  • Copyright (c) 2016 Roice Nelson
• keep ordinary third-party notices if code or substantial portions are incorporated

Approved working posture:

• use the mirrored repo as the canonical local source for the Magic120Cell software lane
• do not clean-room it while the local MIT source is already in hand
• treat the repo as the authoritative local source-of-truth over shallower manual/index mentions

roice3/MagicCube5D

Decision date:

• 2026-05-01

Current licensing judgment:

• usable for HyperTwist
• direct donor candidate
• standard MIT
• the first narrower bounded implementation slice is now landed in current code:
  • dedicated 5D family runtime profile
  • solved-progress telemetry contract
  • persistence, twist-history, and macro-sidecar boundary
  • projection and focus view-profile contract
  • direct-donor attribution boundary
• the row remains only partially incorporated; host-shell ownership, stereo/anaglyph renderer ownership, generic hyper-runtime ownership, generic notation or replay ownership, and broad macro/tutorial shell widening stay deferred

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\roice3\MagicCube5D\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\roice3\MagicCube5D\README.md
• C:\Workspaces\HyperTwist\mirrors\permissive\roice3\MagicCube5D\src\MagicCube5D\workFiles\cube5D.cpp
• C:\Workspaces\HyperTwist\mirrors\permissive\roice3\MagicCube5D\src\MagicCube5D\workFiles\stateTransformer.cpp
• C:\Workspaces\HyperTwist\mirrors\permissive\roice3\MagicCube5D\src\MagicCube5D\workFiles\loader.cpp
• C:\Workspaces\HyperTwist\mirrors\permissive\roice3\MagicCube5D\src\MagicCube5D\workFiles\settings.cpp
• C:\Workspaces\HyperTwist\mirrors\permissive\roice3\MagicCube5D\src\MagicCube5D\workFiles\settings.h
• C:\Workspaces\HyperTwist\mirrors\permissive\roice3\MagicCube5D\src\MagicCube5D\workFiles\twist.h
• C:\HyperTwist\zippedreposource\mc5d_source.zip

Practical obligations:

• preserve the upstream MIT license text from the mirrored repo
• preserve the upstream copyright notice:
  • Copyright (c) 2016 Roice Nelson

Important provenance note:

• HyperTwist also possesses an older local source archive:
  • C:\HyperTwist\zippedreposource\mc5d_source.zip
• that archive contains license.txt with an older broad-use notice rather than the mirrored repo's later MIT file
• current HyperTwist posture:
  • use the mirrored roice3/MagicCube5D repo as the canonical license source
  • retain the older zip as provenance and source-history context, not as the primary legal basis when the mirrored repo already resolves cleanly under MIT

Approved working posture:

• use the mirrored repo as the canonical local source for the MagicCube5D software lane
• preserve normal MIT notices
• keep the older source archive recorded so the lineage of the MagicCube5D lane is not forgotten
• treat the landed bounded runtime-profile and persistence slice as direct-donor first-party implementation rather than a clean-room lane

roice3/MagicTile

Decision date:

• 2026-05-01

Current licensing judgment:

• usable for HyperTwist
• direct donor candidate
• standard MIT

Source basis:

• C:\Workspaces\HyperTwist\mirrors\permissive\roice3\MagicTile\LICENSE
• C:\Workspaces\HyperTwist\mirrors\permissive\roice3\MagicTile\README.md
• C:\HyperTwist\zippedreposource\MagicTile-master.zip

Practical obligations:

• preserve the upstream MIT license text
• preserve the upstream copyright notice:
  • Copyright (c) 2016 Roice Nelson

Approved working posture:

• use the mirrored repo as the canonical local source
• retain the local zip as duplicate source possession, not as a separate unresolved legal lane
• keep ordinary third-party notices if code or substantial portions are incorporated
• keep the live widening bounded to the landed tiling-topology, transform-aware macro remapping, embedded-browser host-decision, and browser state-bridge contract families rather than flattening the row into blanket permission for full host-shell or runtime replacement use
• after the landed Phase 6R-T, Phase 7A, and Phase 7B slices, keep any future MagicTile widening closed by default unless a narrower first-party gap is proven below broad interaction-shell, native renderer, or host-shell ownership

superliminal.com/andrey/mc7d

Decision date:

• 2026-05-01

Current licensing judgment:

• source is locally possessed
• direct donor use is not yet cleared
• license still requires explicit confirmation
• preserve upstream authorship attribution to Andrey Astrelin

Source basis:

• C:\HyperTwist\superliminal.com\superliminal.com\andrey\mc7d\index.html
• C:\HyperTwist\superliminal.com\superliminal.com\andrey\mc7d\instr.html
• C:\HyperTwist\superliminal.com\superliminal.com\andrey\mc7d\MC7D-src-orig.zip
• C:\HyperTwist\zippedreposource\MC7D-src-orig.zip

Important provenance note:

• HyperTwist does possess the local source archive, so MC7D is not a docs-only reconstruction target
• however, a quick archive scan did not surface a bundled top-level LICENSE, COPYING, or equivalent file in the currently inspected source zip

Approved working posture:

• retain the lane as source-possessed and inventory-complete
• do not clean-room it merely because source is absent, because source is in fact present
• do not promote it to direct donor use until the authoritative license/notice posture is explicitly resolved
• if HyperTwist later incorporates ideas, preserve visible source attribution to Andrey Astrelin

superliminal.com/andrey/mpu

Decision date:

• 2026-05-01

Current licensing judgment:

• source is locally possessed
• direct donor use is not yet cleared
• license still requires explicit confirmation
• preserve upstream authorship attribution to Andrey Astrelin

Source basis:

• C:\HyperTwist\superliminal.com\superliminal.com\andrey\mpu\index.html
• C:\HyperTwist\superliminal.com\superliminal.com\andrey\mpu\instr.html
• C:\HyperTwist\superliminal.com\superliminal.com\andrey\mpu\MPUltSrc.zip
• C:\HyperTwist\zippedreposource\MPUltSrc.zip

Important provenance note:

• HyperTwist does possess the local source archive, so MPUlt is not a docs-only reconstruction target
• a quick archive scan did not surface a bundled top-level LICENSE, COPYING, or equivalent file in the currently inspected source zip

Approved working posture:

• retain the lane as source-possessed and inventory-complete
• use the mirrored manual plus local source archive for reference extraction
• do not promote it to direct donor use until the authoritative license/notice posture is explicitly resolved
• if HyperTwist later incorporates ideas, preserve visible source attribution to Andrey Astrelin

superliminal.com/andrey/ms5d

Decision date:

• 2026-05-01

Current licensing judgment:

• source is locally possessed
• direct donor use is not yet cleared
• license still requires explicit confirmation
• preserve upstream authorship attribution to Andrey Astrelin

Source basis:

• C:\HyperTwist\superliminal.com\superliminal.com\andrey\ms5d\index.html
• C:\HyperTwist\superliminal.com\superliminal.com\andrey\ms5d\Simplex5dSrc.zip
• C:\HyperTwist\zippedreposource\Simplex5dSrc.zip

Important provenance note:

• HyperTwist does possess the local source archive for Magic Simplex 5D
• a quick archive scan did not surface a bundled top-level LICENSE, COPYING, or equivalent file in the currently inspected source zip

Approved working posture:

• retain the lane as source-possessed and inventory-complete
• do not misclassify it as missing-source
• do not promote it to direct donor use until the authoritative license/notice posture is explicitly resolved
• if HyperTwist later incorporates ideas, preserve visible source attribution to Andrey Astrelin

superliminal.com/andrey/mht633

Decision date:

• 2026-05-01

Current licensing judgment:

• executable/manual surface is locally possessed
• source code is not locally possessed
• direct donor use is not cleared
• preserve upstream authorship attribution to Andrey Astrelin

Source basis:

• C:\HyperTwist\superliminal.com\superliminal.com\andrey\mht633\index.html
• C:\HyperTwist\superliminal.com\superliminal.com\andrey\mht633\instr.html
• C:\HyperTwist\superliminal.com\superliminal.com\andrey\mht633\M3dHT633.zip
• C:\HyperTwist\superliminal.com\superliminal.com\andrey\mht633\logs\*

Important provenance note:

• the retained download archive currently exposes runtime binaries only:
  • m3dht633.exe
  • bundled DirectX DLLs
• HyperTwist also now possesses the same runtime archive in the central zip stash:
  • C:\HyperTwist\zippedreposource\M3dHT633.zip
• a quick archive inspection did not surface source code or a bundled top-level LICENSE, COPYING, or equivalent file
• this makes Magic Hyperbolic Tile {6,3,3} a behavior-spec / clean-room reverse-engineering candidate rather than a direct-source donor

Approved working posture:

• retain the lane as executable/manual/source-behavior reference only
• do not pretend local source exists when it does not
• if HyperTwist pursues implementation, use:
  • the manual pages
  • observed runtime behavior
  • persisted solve logs
  • visible UI/control semantics as clean-room input for a behavioral spec
• preserve visible source attribution to Andrey Astrelin

loopover

Decision date:

• 2026-05-01

Current licensing judgment:

• explicit MIT
• local source zip is possessed
• direct donor use is allowed

Source basis:

• C:\HyperTwist\zippedreposource\loopover-master.zip
• bundled loopover-master/LICENSE
• bundled loopover-master/README.md

Practical obligations:

• preserve the upstream MIT license text
• preserve the upstream copyright notice:
  • Copyright (c) 2020 Janis Pritzkau

Approved working posture:

• treat loopover as a normal permissive donor candidate
• preserve ordinary MIT notices if code or substantial portions are incorporated
• annul the earlier HyperTwist governance choice that kept this lane in clean-room-only posture

Hypercubers/sphenic-biaxe

Decision date:

• 2026-05-01

Current licensing judgment:

• explicit dual MIT OR Apache-2.0
• locally possessed source zip
• not blocked

Source basis:

• C:\HyperTwist\zippedreposource\sphenic-biaxe-main.zip
• bundled sphenic-biaxe-main/Cargo.toml
• bundled sphenic-biaxe-main/LICENSE-MIT
• bundled sphenic-biaxe-main/LICENSE-APACHE

Practical obligations:

• preserve both upstream license texts or the effective chosen path
• preserve upstream copyright attribution:
  • Andrew Farkas

Approved working posture:

• treat as a permissive source lane
• do not misclassify it as unclear-license or missing-license

Sonicpineapple/Green

Decision date:

• 2026-05-01

Current licensing judgment:

• no explicit top-level license text surfaced in the currently inspected local zip
• do not treat as a direct donor
• keep in clean-room custody

Source basis:

• C:\HyperTwist\zippedreposource\Green-master.zip
• bundled Green-master/Cargo.toml
• bundled Green-master/README.md

Important provenance note:

• the local zip exposes a manifest and README, but no bundled top-level LICENSE, COPYING, or equivalent file surfaced in the current inspection
• current HyperTwist posture is governed by caution, not by assuming implied permission from a public repo

Approved working posture:

• keep this lane in clean-room implementation
• do not use directly unless the authoritative upstream license is later captured explicitly

openslidy

Decision date:

• 2026-05-01

Current licensing judgment:

• no explicit top-level license text surfaced in the currently inspected local zip
• do not treat as a direct donor
• keep in clean-room custody

Source basis:

• C:\HyperTwist\zippedreposource\openslidy-main.zip
• bundled openslidy-main/README.md

Approved working posture:

• keep this lane in clean-room implementation
• do not promote it to direct donor use without an explicit captured license

heav-4/relocation

Decision date:

• 2026-05-01

Current licensing judgment:

• no explicit top-level license text surfaced in the currently inspected local zip
• do not treat as a direct donor
• keep in clean-room custody

Source basis:

• C:\HyperTwist\zippedreposource\relocation-main.zip
• bundled relocation-main/README.md

Approved working posture:

• keep this lane in clean-room implementation
• do not promote it to direct donor use without an explicit captured license