# 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
- `roice3/MagicTile` remains partially incorporated
- 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 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](C:/HyperTwist/docs/ops/HYPERTWIST_MPL_BOUNDARY_AND_NON_GPL_USAGE_DOCTRINE_2026-05-25.md:1)
- the dedicated release-placement checklist for that route is:
  - [HYPERTWIST_MPL_DISTRIBUTION_PLACEMENT_CHECKLIST_2026-05-25.md](C:/HyperTwist/docs/ops/HYPERTWIST_MPL_DISTRIBUTION_PLACEMENT_CHECKLIST_2026-05-25.md:1)
  - 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`

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`

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
- not a clean-room requirement by default
- treat as a landed commercially sensitive bounded sidecar preserve lane through `Phase 4R-F`

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

### `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](C:/HyperTwist/docs/HYPERTWIST_PHASE_3R_PACKET_3R_E_TALKINGHEAD_IMPLEMENTATION_2026-05-13.md:1)

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](C:/HyperTwist/docs/HYPERTWIST_PHASE_3R_PACKET_3R_C_ECHARTS_IMPLEMENTATION_2026-05-13.md:1), 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 and transform-aware macro
  remapping contract families rather than flattening the row into blanket permission for full
  host-shell or runtime replacement use
- after the landed `Phase 6R-T` slice, keep any future `MagicTile` widening closed by default
  unless a narrower first-party gap is proven below broad interaction-shell 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
