# HyperTwist Canonical Restart Reconciliation

Created on `2026-05-12`

## Purpose

This document reconciles the current HyperTwist restart authority across the three canonical planning/governance locations that were parsed in this pass:

- `C:\HyperTwist\docs`
- `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse`
- `C:\Workspaces\HyperTwist`

It exists to prevent future sessions from mixing:

- portfolio posture
- historical phase-lineage notes
- clean-room workflow precedent
- actual live implementation truth

It now also exists to prevent future sessions from collapsing:

- bookmarked
- queued
- source-read
- retained
- product-fit
- implementation-authorized
- implemented

into one vague repo judgment.

## Scope of this reconciliation

This pass parsed the canonical docs, ledgers, prompts, clean-room notes, and workspace manifest that future sessions are most likely to treat as authority.

It was an authority-led end-to-end documentation parse.

It was not a line-by-line reread of every mirror, archive, zipped source copy, or generated output folder.

`C:\HyperTwist\docs2` was requested as part of the canonical sweep, but that path did not exist at audit time.

Current handling:

- treat `docs2` as absent
- do not assume it contains missing authority
- if it is created later, it must inherit the restart authority order defined here

## Reconciled current truth

The current reconciled HyperTwist truth is:

- current curated HyperTwist shallow-eval set: `71` repos
- currently verified live in checked `UnrealHyperTwist` surfaces: `20`
- currently verified live permissive lanes: `13`
- currently verified live boundary-sensitive lanes: `6`
- currently verified live restrictive lanes: `1`

`2026-06-12` routing correction:

- the `2026-05-12` snapshot above remains historically accurate for that restart pass
- preserve the already-landed first-party `Phase 4R-F` outputs
- for current work, do not treat `remotion-dev/remotion` as a default future boundary-sensitive widening lane; route future donor-backed widening through restrictive custody and explicit clean-room/specification work, or replace it with a first-party Unreal-native export path

The thirteen currently verified live permissive lanes are:

- `Aarav2709/KubeTimr`
- `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`
- `poliva/cubedex`
- `newyork-anthonyng/rubiks-cross-trainer`

The six currently verified live boundary-sensitive lanes are:

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

The one currently verified live restrictive lane is:

- `onionhoney/roux-trainers`

That restrictive lane must be treated as:

- properly clean-roomed
- properly implemented afterward
- preserved as the current clean-room precedent
- not to be reopened as an unresolved direct-donor contamination event

The remaining `51` rows are not to be treated as already implemented.

`Phase 0R` is now closed for that non-live set.

Those rows now resolve into:

- retained straight-permissive candidates
- retained boundary-sensitive candidates
- retained restrictive clean-room candidates
- retained benchmark, oracle, and clean-room-later rows
- discarded active-set rows

## 2026-05-14 intake and product-fit doctrine update

HyperTwist now treats the following as mandatory doctrine:

- a bookmarked repo is only intake
- a queued repo is only sequencing
- a source-read repo is only evidence gained
- a retained repo is only a repo that survived evaluation in some posture
- product-fit is a separate judgment from retention
- implementation-authorized is a separate judgment from product-fit
- implemented means landed in first-party product surfaces under explicit implementation authority

Canonical doctrine docs:

- `docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md`
- `docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md`

Operational implication:

- do not let bookmark presence, queue position, frequent mention, planning artifacts, or docs metadata masquerade as product intent or proof of implementation
- donor strength and legal posture are separate axes
- permissive status does not automatically win a lane
- restrictive or boundary-sensitive status does not automatically lose a lane
- harder route does not mean weaker donor
- routine live or product-surface scanning is no longer the default evaluation step
- assume a repo is not implemented unless explicit implementation authority says otherwise
- verify current implementation state only when the active task depends on that fact

## Canonical-location findings

### `C:\HyperTwist\docs`

The repo docs already carried the correct core implementation truth from `2026-05-11`, but they still needed:

- explicit cross-location reconciliation
- explicit demotion of old parse-side `Phase 4` continuation docs for restart work
- an explicit post-`Phase 1R` sequence instead of only a `Phase 0R` / `Phase 1R` stop point

### `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse`

The parse repo still contains essential governance material, especially:

- `06-project-agnostic-repo-evaluation-modus-operandi.md`
- `07-benchmark-oracle-vs-clean-room-implementation.md`
- `88-roadmap-implementation-workbook.md`
- `89-phase-0-and-phase-1-bootstrap-packet.md`

But several parse-side docs were stale as active restart authority:

- `README.md` still foregrounded the old `75`-row canon and old authority chain
- `90-clean-room-safe-project-context.md` still claimed `Aarav2709/KubeTimr` was already live and still framed the old active `Phase 4` lane as current
- `96-hypertwist-live-execution-roadmap.md`, `116-hypertwist-handoff.md`, and `119-hypertwist-current-execution-reality-and-phase-discipline.md` still framed the old bounded `Phase 4` continuation lane as the active restart authority

Those docs remain useful lineage.

They are no longer the primary restart authority.

### `C:\Workspaces\HyperTwist`

The workspace repo remains the external control-plane and clean-room handoff surface.

It needed correction because:

- the root `README.md` did not surface the current `71` / `9` / `8` / `1` truth
- clean-room notes still described `onionhoney/roux-trainers` as the current active next restrictive lane rather than the preserved already-landed restrictive precedent
- `repos.manifest.json` did not surface the `Phase 0R` reset and still contained a stale app handoff pointer

## Restart authority order

For restart and future widening decisions, use this order:

1. `docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md`
2. `docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md`
3. `docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md`
4. `docs/HT_REPO_INCORPORATION_AUDIT_2026-05-11.md`
5. `docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md`
6. packet-level deep-source authority docs for any repo being implemented:
   - `docs/HYPERTWIST_PHASE_0R_PACKET_0R_A_EVALUATION_2026-05-12.md`
   - later `Phase 0R` packet docs as they are upgraded to the same standard
7. `docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md`
8. `docs/REPO_LICENSE_TRACKING.md`
9. `docs/v6_5_deep_manual_pack/README.md`
10. `docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md`
11. `docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md`
12. safe parse/workbook governance docs:
   - `06-project-agnostic-repo-evaluation-modus-operandi.md`
   - `07-benchmark-oracle-vs-clean-room-implementation.md`
   - `88-roadmap-implementation-workbook.md`
   - `89-phase-0-and-phase-1-bootstrap-packet.md`
   - `90-clean-room-safe-project-context.md`
   - `122-hypertwist-phase-0r-restart-authority-and-sequencing.md`
13. the current v6.3 CSV boards and prompts

Use the following only as lineage or historical context unless a restart doc explicitly points back to them:

- `96-hypertwist-live-execution-roadmap.md`
- `116-hypertwist-handoff.md`
- `119-hypertwist-current-execution-reality-and-phase-discipline.md`

## Restart doctrine

The restart is not a mass revert.

It is a provenance and planning reset around the remaining `51` current non-live rows while preserving the twenty already-landed lanes.

Required standing rules:

- preserve the twenty landed lanes
- preserve `onionhoney/roux-trainers` as the only currently verified landed restrictive clean-room lane
- do not collapse `bookmarked`, `queued`, `source-read`, `retained`, `product-fit`, `implementation-authorized`, and `implemented`
- do not collapse `selected`, `retained`, `integrate`, `repurpose`, or `donor bench` into `already implemented`
- do not widen new donor-shaped implementation from the remaining `51` current non-live rows until the closed packet sequence routes it
- before implementing any retained repo, read the packet-level deep-source authority doc for that repo class if one exists

## 2026-05-12 packet-depth correction

`Packet 0R-A` was originally closed correctly as a retained-set packet, but too shallowly.

Current correction:

- `docs/HYPERTWIST_PHASE_0R_PACKET_0R_A_EVALUATION_2026-05-12.md` is now the deep-source integration authority for the seven `0R-A` repos
- it records what source was actually read, what value must be salvaged, and why any surface is not promoted
- future `Phase 0R` packets should use the same standard rather than only describing keep/discard posture

Practical implication:

- if a future instance is about to integrate `Hyperspeedcube`, `qbr`, `rubix-cube-solver`, `KubeTimr`, `MagicTile`, `Magic120Cell`, or `MagicCube5D`, it should not start from the shallow CSV row or bucket label
- it should start from `0R-A`, then check `REPO_LICENSE_TRACKING.md`, then return to the schedule

`Packet 0R-D` required one more boundary rule because it covers restrictive clean-room rows.

Current correction:

- `docs/HYPERTWIST_PHASE_0R_PACKET_0R_D_EVALUATION_2026-05-13.md` is now the governance and Model A authority for the four restrictive retained rows
- it records what source was actually read, what value must be salvaged, what was not promoted, and why
- the repo-specific scrubbed files in `C:\Workspaces\HyperTwist\clean-room-specs\` remain the only implementation-safe Model B handoff inputs

Practical implication:

- if a future instance is about to implement `cubing/alg.js`, `cubing/twisty.js`, `HactarCE/2x2x2x2-Scrambler`, or `kash/cubedesk`, it must read `0R-D`, then `REPO_LICENSE_TRACKING.md`, then the repo-specific scrubbed Model A handoff
- it must not treat `0R-D` itself as a substitute for the scrubbed handoff during Model B work

## Restart phase sequence

### Phase `0R` — deep repo source integration evaluation

Goal:

- deeply evaluate the remaining `51` rows repo by repo

Required output per retained row:

- final license posture
- keep / promote / demote / benchmark / discard decision
- implementation lane:
  - straight permissive implementation
  - bounded dependency or adapter
  - restrictive clean-room
  - benchmark/oracle only
  - discard
- evidence links
- compliance notes
- scheduling wave

Exit gate:

- every remaining row has a ratified current-state decision

### Phase `1R` — contract and handoff overhaul

Goal:

- rebuild the implementation-facing contract layer from only:
  - the six already-landed lanes
  - the retained subset that survives `Phase 0R`

Required output:

- refreshed CSV boards
- refreshed license tracker
- refreshed roadmap and handoff docs
- refreshed clean-room inventory
- refreshed Model B allowlist and source-boundary docs

Exit gate:

- no retained row depends on stale pre-reset wording to describe its next action

### Phase `2R` — retained-set ratification and packet design

Goal:

- turn the retained post-`Phase 0R` set into an implementation-ready backlog

Required output:

- retained-set implementation board
- package ordering by subsystem
- ownership boundaries
- acceptance criteria for each retained lane

Exit gate:

- every retained lane has an implementation packet class and an explicit entry point into the roadmap

### Phase `3R` — permissive direct-implementation waves

Goal:

- execute the retained straight-permissive lanes first

Expected lane types:

- direct donor implementation
- bounded first-party adaptation
- permissive subsystem extraction

Exit gate:

- the high-value retained permissive rows that clearly shorten delivery are either landed or deliberately deferred

### Phase `4R` — boundary-sensitive dependency and sidecar waves

Goal:

- execute the retained mixed-term, attribution-heavy, sidecar, and adapter-heavy lanes

Expected lane types:

- `MPL`-side dependency or adapter use
- attribution-preserved donor use
- commercial or mixed-license bounded sidecars
- explicit enterprise-slice exclusion

Exit gate:

- every retained boundary-sensitive row has a closed consumption plan or a discard decision

### Phase `5R` — restrictive clean-room waves

Goal:

- execute retained restrictive lanes through refreshed Model A / Model B separation

Expected lane types:

- new restrictive clean-room implementations
- refreshed restrictive handoff dossiers
- fresh clean implementation packets using only approved safe artifacts

Exit gate:

- every retained restrictive lane is either:
  - landed through clean-room
  - still queued with a refreshed clean-room chain
  - or deliberately discarded

### Phase `6R` — simulation, recognition, XR, and support-plane widening

Goal:

- widen product capability only from the retained evaluated set

Expected focus:

- hyper/simulation widening
- recognition and reconstruction widening
- XR and presentation widening
- support-plane tooling that survives retention review

Exit gate:

- widening is traceable to retained rows rather than stale portfolio optimism

### Phase `7R` — benchmark, oracle, discard, and release-hardening closure

Goal:

- close the remaining oracle/reference/discard decisions and tie them to validation

Expected focus:

- benchmark harnesses
- solver/timer/reference comparisons
- discard memorialization
- compliance and notice closure
- release-hardening checks

Exit gate:

- no retained benchmark/reference row remains in ambiguous limbo

## Recommended `Phase 0R` packet order

Start with the highest-value lanes that can change the retained-set shape fastest.

### Packet `0R-A` — permissive architecture anchors

Start here:

- `HactarCE/Hyperspeedcube`
- `kkoomen/qbr`
- `vivaansinghvi07/rubix-cube-solver`
- `Aarav2709/KubeTimr`
- `roice3/MagicTile`
- `roice3/MagicCube5D`
- `roice3/Magic120Cell`

Why first:

- these rows are structurally important
- several can become direct implementation or bounded donor lanes without clean-room overhead
- they shape later simulation, recognition, timer, and hypercube planning

### Packet `0R-B` — remaining permissive product donors

Next:

- retained training, solver, analytics, curriculum, and browser-support rows such as:
  - `cahidenes/rubiks-cube-solver`
  - `tentone/rubix-solver`
  - `Hypercubers/hypercubing.xyz`
  - `apache/echarts`
  - `ecomfe/zrender`
  - `ecomfe/echarts-gl`
  - retained `google/model-viewer` and `pmndrs/*` support rows

Why next:

- they are likely to remain permissive implementation candidates
- they benefit from anchor decisions made in `0R-A`

### Packet `0R-C` — boundary-sensitive retained rows

Then:

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

Why here:

- these are not restrictive clean-room rows
- but they still need explicit adapter, notice, asset-term, enterprise-slice, or commercial-boundary decisions before implementation resumes

### Packet `0R-D` — restrictive clean-room re-selection

Then:

- `cubing/alg.js`
- `cubing/twisty.js`
- `HactarCE/2x2x2x2-Scrambler`
- `kash/cubedesk`

Why here:

- these are the restrictive lanes still selected but not yet verified live
- they need refreshed retention decisions before any new Model A / Model B work resumes

### Packet `0R-E` — reference, benchmark, reserve, and discard closure

Then:

- `cs0x7f/cstimer`
- `brownan/Rubiks-Cube-Solver`
- `efrantar/rob-twophase`
- `ShellPuppy/RCube`
- `vwcwong/CubeSim`
- `MathewKJ2048/Rubiks-cube-simulator`
- `aMonteSl/CodeXR`
- `AviKaufman/Rubix-cube-trainer`
- `alinen/cube`
- `ambisinister/blindsolve`
- `brianpeiris/RiftSketch`
- `yakupbilen/drl-rubiks-cube`

Why last:

- these rows are more likely to end as oracle, benchmark, reserve, or discard decisions than as near-term implementation packets

## Documentation maintenance rule

After this reconciliation:

- new restart docs must say whether they are describing `live implementation truth`, `portfolio posture`, or `historical lineage`
- no canonical doc should use `implemented`, `full`, or `already live` for a repo unless current first-party evidence supports it
- no clean-room doc should describe `onionhoney/roux-trainers` as the next pending restrictive implementation lane without also saying it is already the landed restrictive clean-room precedent

## Current packet status

`Packet 0R-A`, `Packet 0R-B`, `Packet 0R-C`, `Packet 0R-D`, `Packet 0R-E`, `Phase 1R`, the live-lane preservation audit, `Phase 2R-A`, `Phase 2R-B`, and `Phase 2R-C` are now closed as authority steps.

See:

- `docs/HYPERTWIST_PHASE_0R_PACKET_0R_A_EVALUATION_2026-05-12.md`
- `docs/HYPERTWIST_PHASE_0R_PACKET_0R_B_EVALUATION_2026-05-12.md`
- `docs/HYPERTWIST_PHASE_0R_PACKET_0R_C_EVALUATION_2026-05-12.md`
- `docs/HYPERTWIST_PHASE_0R_PACKET_0R_D_EVALUATION_2026-05-13.md`
- `docs/HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.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`

Result:

- all seven `0R-A` repos remain retained
- all thirty-six `0R-B` repos remain retained
- all six `0R-C` repos remain retained
- all four `0R-D` repos remain retained
- `9` `0R-E` rows remain retained only as benchmark, oracle, or clean-room-later reservations
- `3` `0R-E` rows are now discarded from the active retained set
- `Packet 0R-B` is now a deep-source integration authority packet, not merely a permissive backlog summary
- `Packet 0R-C` is now the deep-source boundary-use authority for the mixed, attributed, asset-term, and commercial rows
- `Packet 0R-D` is now the governance and Model A authority for the restrictive clean-room rows
- `Packet 0R-E` is now the deep-source benchmark, reference, clean-room-later, and discard authority for its twelve rows
- `Phase 1R` is now the retained-set contract and handoff authority for all post-`Phase 0R` routing
- the eleven already-live rows now also have symmetric source-backed preservation authority through the live-lane audit
- `Phase 2R-A` is now the ownership and acceptance authority for the five core retained permissive rows
- `Phase 2R-B` is now the ownership and acceptance authority for the primary retained permissive support-plane rows in scope
- `Phase 2R-C` is now the ownership and acceptance authority for the final residual `0R-B` permissive rows
- `Phase 2R` is now fully closed for the retained permissive set
- `Phase 3R-A` is now the landed implementation authority for `Aarav2709/KubeTimr`
- `Phase 3R-B` is now the landed implementation authority for `Hypercubers/hypercubing.xyz`
- `Phase 3R-C` is now the landed implementation authority for `apache/echarts`
- `Phase 3R-D` is now the landed implementation authority for `google/model-viewer`
- `Aarav2709/KubeTimr` is now the sixth permissive live lane and seventh live row overall
- `Hypercubers/hypercubing.xyz` is now the seventh permissive live lane and eighth live row overall
- `apache/echarts` is now the eighth permissive live lane and ninth live row overall
- `google/model-viewer` is now the ninth permissive live lane and tenth live row overall
- `met4citizen/TalkingHead` is now the tenth permissive live lane and eleventh live row overall
- `mrdoob/three.js` is now the eleventh permissive live lane and twelfth live row overall
- `pmndrs/react-three-fiber` is now the twelfth permissive live lane and thirteenth live row overall
- `pmndrs/xr` is now the thirteenth permissive live lane and fourteenth live row overall
- `HactarCE/Hyperspeedcube`, `kkoomen/qbr`, `vivaansinghvi07/rubix-cube-solver`, and `roice3/MagicTile` remain packetized for `Phase 6R`
- `Hypercubers/hypercubing.xyz` is now a landed permissive knowledge/curriculum/community lane rather than the next straight permissive candidate
- `apache/echarts` is now a landed permissive analytics/reporting lane rather than the next straight permissive candidate
- `google/model-viewer` plus `KhronosGroup/glTF-Sample-Viewer` are now the landed browser presentation/editor and standards-QA `3R-D` lane
- `met4citizen/TalkingHead` is now the landed embodied companion `3R-E` lane
- `mrdoob/three.js`, `pmndrs/react-three-fiber`, and `pmndrs/xr` are now the landed browser spatial owner trio through `3R-F`
- `cahidenes/rubiks-cube-solver` and `tentone/rubix-solver` now form the retained recognition-comparison adjunct lane, not a currently open `Phase 6R-*` packet route
- `NuiLab/code-vr` now forms the retained `6R-F` symbolic-to-spatial XR pedagogy experiment lane
- `pissang/claygl` and `pissang/clay-viewer` now form the retained optional `3R-G` alternative browser comparison lane
- `cubing/cubing.js` is now the fifteenth live row overall and one live boundary-sensitive lane through the closed `Phase 4R-A` classic-cubing adapter packet
- `cutelyaware/magiccube4d` is now the sixteenth live row overall and the second live boundary-sensitive lane through the closed `Phase 4R-B` attributed legacy `4D` adapter packet
- `google/model-viewer/packages/shared-assets` is now the seventeenth live row overall and the third live boundary-sensitive lane through the closed `Phase 4R-C` shared-assets allowlist packet
- `PostHog/posthog` is now the eighteenth live row overall and the fourth live boundary-sensitive lane through the closed `Phase 4R-D` control-plane packet
- `screenpipe/screenpipe` is now the nineteenth live row overall and the fifth live boundary-sensitive lane through the closed `Phase 4R-E` capture-history packet
- `remotion-dev/remotion` is now the twentieth live row overall and the sixth live boundary-sensitive lane through the closed `Phase 4R-F` media-export packet

License-tracking boundary:

- `docs/REPO_LICENSE_TRACKING.md` is the canonical repo-row legal and attribution ledger
- `docs/v6_5_deep_manual_pack/HyperTwist/LICENSETRACKING.md` is policy-only and must not become a second repo-row legal ledger
- `docs/HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md` is the source-backed preservation authority for the twenty already-live rows
- `docs/HYPERTWIST_PHASE_2R_PACKET_2R_A_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md` is the packet authority for the five core retained permissive rows once source extraction has already been read
- `docs/HYPERTWIST_PHASE_2R_PACKET_2R_B_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md` is the packet authority for the primary retained permissive support-plane rows once source extraction has already been read
- `docs/HYPERTWIST_PHASE_2R_PACKET_2R_C_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md` is the packet authority for the final residual permissive `0R-B` adjunct and alternative-support rows once source extraction has already been read
- `Packet 0R-A`, `Packet 0R-B`, and `Packet 0R-C` are the source-value and exclusion-rationale authorities for their retained rows
- `Packet 0R-D` is the governance and Model A authority for its retained rows, but not the Model B handoff artifact
- `Packet 0R-E` is the source-value and discard-rationale authority for its twelve rows
- those packet docs must now also carry concise implementation-facing licensing snapshots so an integrating instance does not miss the legal posture at handoff time
- full license, attribution, notice, asset-term, and provenance obligations still belong in `docs/REPO_LICENSE_TRACKING.md`

## Practical next move

The next bounded move is:

1. preserve the twenty landed rows as the current truth
2. keep `Aarav2709/KubeTimr`, `Hypercubers/hypercubing.xyz`, `apache/echarts`, `google/model-viewer`, `met4citizen/TalkingHead`, `mrdoob/three.js`, `pmndrs/react-three-fiber`, `pmndrs/xr`, `cubing/cubing.js`, `cutelyaware/magiccube4d`, `google/model-viewer/packages/shared-assets`, `PostHog/posthog`, `screenpipe/screenpipe`, and `remotion-dev/remotion` on preserve-and-enhance footing through their landed packets
3. open `Phase 5R-A`
4. widen `cubing/alg.js` as the first refreshed clean-room implementation lane from its scrubbed Model A dossier, while keeping the optional `Phase 3R-G` browser comparison lane deferred unless the landed primary browser spatial stack exposes a real gap