Reconcile HyperTwist Phase 0R restart authority

docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md

@@ -0,0 +1,402 @@
+# 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
+
+## 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: `6`
+- currently verified live permissive lanes: `5`
+- currently verified live restrictive lanes: `1`
+
+The five currently verified live permissive lanes are:
+
+- `abunickabhi/5style-Trainer`
+- `tao-yu/Alg-Trainer`
+- `Lykos/cube_trainer`
+- `poliva/cubedex`
+- `newyork-anthonyng/rubiks-cross-trainer`
+
+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 `65` rows are not to be treated as already implemented.
+
+They are the `Phase 0R` evaluation backlog.
+
+## 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` / `6` / `5` / `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/HT_REPO_INCORPORATION_AUDIT_2026-05-11.md`
+3. `docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md`
+4. `docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md`
+5. `docs/REPO_LICENSE_TRACKING.md`
+6. `docs/v6_5_deep_manual_pack/README.md`
+7. `docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md`
+8. `docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md`
+9. 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`
+10. 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 `65` rows while preserving the six already-landed lanes.
+
+Required standing rules:
+
+- preserve the six landed lanes
+- preserve `onionhoney/roux-trainers` as the only currently verified landed restrictive clean-room lane
+- do not collapse `selected`, `retained`, `integrate`, `repurpose`, or `donor bench` into `already implemented`
+- do not widen new donor-shaped implementation from the remaining `65` until `Phase 0R` and `Phase 1R` close
+
+## Restart phase sequence
+
+### Phase `0R` — deep repo source integration evaluation
+
+Goal:
+
+- deeply evaluate the remaining `65` 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
+
+## Practical next move
+
+The next bounded move is:
+
+1. open `Phase 0R`
+2. start `Packet 0R-A`
+3. ratify the retained-set decision for the architecture anchors before widening any later roadmap lane

docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md

@@ -6,6 +6,20 @@ Created on `2026-05-11`
 
 This document is the canonical current-state correction for HyperTwist repo provenance, implementation truth, and next-step sequencing.
 
+## 2026-05-12 reconciliation note
+
+This schedule was rechecked on `2026-05-12` against:
+
+- `C:\HyperTwist\docs`
+- `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse`
+- `C:\Workspaces\HyperTwist`
+
+The current restart authority addendum is:
+
+- `docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md`
+
+Use that document when a future session needs the cross-location restart authority order, the stale-doc demotions, and the explicit post-`Phase 1R` sequence.
+
 Use it when a future model, operator, or reviewer needs one unambiguous answer to all of the following:
 
 - what is already implemented right now
@@ -163,6 +177,39 @@ Already-landed first-party work can remain.
 
 New widening should wait.
 
+## Subsequential restart phases
+
+After `Phase 0R` and `Phase 1R`, the restart sequence is:
+
+### Phase `2R` — retained-set ratification and packet design
+
+- convert the post-`Phase 0R` retained rows into an implementation-ready backlog
+- define ownership boundaries, packet classes, acceptance criteria, and subsystem entry points
+
+### Phase `3R` — permissive direct-implementation waves
+
+- execute the retained straight-permissive lanes first
+- favor rows that can become first-party capability quickly without clean-room overhead
+
+### Phase `4R` — boundary-sensitive adapter and sidecar waves
+
+- close the mixed-term, attribution-heavy, enterprise-slice, and commercial-boundary rows
+- prefer adapter, dependency, or bounded sidecar use where the retained posture says that is the cleanest path
+
+### Phase `5R` — restrictive clean-room waves
+
+- refresh Model A / Model B dossiers for the retained restrictive rows
+- implement only from the refreshed clean-room chain
+
+### Phase `6R` — retained-set capability widening
+
+- widen recognition, simulation, hyper, XR, and support-plane work only from the retained evaluated set
+
+### Phase `7R` — benchmark, discard, and release-hardening closure
+
+- close oracle/reference/discard decisions
+- tie benchmark rows to validation instead of leaving them as ambiguous backlog
+
 ## Scheduling the remaining repos
 
 The right schedule now is not one giant undifferentiated queue.

docs/HYPERTWIST_ROADMAP_OVERHAUL_EXPANSION_GUIDE.md

@@ -15,6 +15,18 @@ This file must now be read together with:
 - `docs/HT_REPO_INCORPORATION_AUDIT_2026-05-11.md`
 - `docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md`
 
+## 2026-05-12 restart-authority correction
+
+The canonical cross-location restart reconciliation now lives in:
+
+- `docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md`
+
+Implication:
+
+- older parse-side `Phase 4` continuation docs remain useful lineage for the bounded dashboard-consumer lane that was already landed
+- they are not the primary restart authority for the remaining donor portfolio
+- the restart authority is now the repo-doc reconciliation plus the `Phase 0R` / `Phase 1R` reset schedule
+
 Current verified truth:
 
 - current curated HyperTwist shallow-eval set: `71` repos
@@ -131,8 +143,10 @@ For the current code-reality synthesis and active phase-discipline note, also re
 
 - `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\116-hypertwist-handoff.md`
 - `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\119-hypertwist-current-execution-reality-and-phase-discipline.md`
+- `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\122-hypertwist-phase-0r-restart-authority-and-sequencing.md`
 - `C:\HyperTwist\docs\arch\HYPERTWIST_PI_PRIMING_FINDINGS_2026-05-04.md`
 - `C:\HyperTwist\docs\HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md`
+- `C:\HyperTwist\docs\HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md`
 
 ## Higher-detail planning references
 

docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md

@@ -15,7 +15,9 @@ Purpose:
 - curated first-party docs in:
   - `C:\HyperTwist\docs\MODEL_B_SOURCE_ACCESS_BOUNDARY.md`
   - `C:\HyperTwist\docs\HT_REPO_INCORPORATION_AUDIT_2026-05-11.md`
+  - `C:\HyperTwist\docs\HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md`
   - `C:\HyperTwist\docs\HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md`
+  - `C:\HyperTwist\docs\HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md`
   - `C:\HyperTwist\docs\REPO_LICENSE_TRACKING.md`
   - `C:\HyperTwist\docs\arch\HYPERTWIST_IMPORTED_GENERATED_MODE_EXECUTOR_PACKET_2026-05-05.md`
   - `C:\HyperTwist\docs\v6_5_deep_manual_pack\README.md`
@@ -33,6 +35,7 @@ Purpose:
   - `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\88-roadmap-implementation-workbook.md`
   - `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\89-phase-0-and-phase-1-bootstrap-packet.md`
   - `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\90-clean-room-safe-project-context.md`
+  - `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\122-hypertwist-phase-0r-restart-authority-and-sequencing.md`
 - first-party staging docs and acceptance materials in:
   - `C:\Workspaces\HyperTwist\implementation-workspaces\scratch\roadmap-bootstrap\docs\contracts\*`
   - `C:\Workspaces\HyperTwist\implementation-workspaces\scratch\roadmap-bootstrap\docs\architecture\*`
@@ -92,6 +95,7 @@ Implications for `Model B`:
 - `Model B` may work with the already-landed first-party Unreal outputs and scrubbed clean-room specs for that lane
 - `Model B` must still not read the restrictive mirror itself
 - do not describe other restrictive HyperTwist repos as already landed unless the same level of clean-room and live-evidence closure is explicitly documented
+- for future restrictive-lane widening, wait for `Phase 0R` retention and `Phase 1R` handoff refresh before selecting the next clean-room target
 
 ## Brownan / Oracle clarification
 

docs/REPO_LICENSE_TRACKING.md

@@ -63,6 +63,7 @@ Reset rule:
 
 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_REPO_STATE_BOARD_2026-05-11.md`

docs/repo_portfolio_unified_branch_seed_prompt_v6_3.md

@@ -10,18 +10,19 @@ Treat this branch as a v6.3-governed portfolio session.
 5. API.MD
 6. LICENSETRACKING.MD
 7. SKILLS.MD
-8. HT_REPO_INCORPORATION_AUDIT_2026-05-11.md
-9. HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md
-10. HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md
-11. repo_portfolio_unified_v6_3.xlsx
-12. repo_portfolio_unified_phase_g_v6_3.csv
-13. repo_portfolio_unified_operational_v6_3.csv
-14. repo_portfolio_unified_source_audit_v6_3.csv
-15. repo_portfolio_unified_vscode_packets_v6_3.csv
-16. repo_portfolio_unified_merger_matrix_v6_3.csv
-17. repo_portfolio_unified_cluster_narratives_v6_3.csv
-18. repo_portfolio_unified_copyleft_strategy_matrix_v6_3.csv
-19. repo_portfolio_unified_re_layer_matrix_v6_3.csv
+8. HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md
+9. HT_REPO_INCORPORATION_AUDIT_2026-05-11.md
+10. HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md
+11. HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md
+12. repo_portfolio_unified_v6_3.xlsx
+13. repo_portfolio_unified_phase_g_v6_3.csv
+14. repo_portfolio_unified_operational_v6_3.csv
+15. repo_portfolio_unified_source_audit_v6_3.csv
+16. repo_portfolio_unified_vscode_packets_v6_3.csv
+17. repo_portfolio_unified_merger_matrix_v6_3.csv
+18. repo_portfolio_unified_cluster_narratives_v6_3.csv
+19. repo_portfolio_unified_copyleft_strategy_matrix_v6_3.csv
+20. repo_portfolio_unified_re_layer_matrix_v6_3.csv
 
 ## Session Rules
 - Licensing is non-gating.
@@ -31,6 +32,7 @@ Treat this branch as a v6.3-governed portfolio session.
 - Treat v6.3 as canonical; legacy packs are reference only.
 - Do not call a HyperTwist repo `implemented`, `full`, or `already live` unless the current-state docs or 2026-05-11 CSV columns say it is landed/live.
 - Prefer the state board when you need a human-readable repo-by-repo answer for all `71` HyperTwist rows.
+- Use the `2026-05-12` reconciliation doc when a session needs the current restart authority order or the demotion of older parse-side `Phase 4` continuity docs.
 - For HyperTwist specifically, remember the current verified truth:
   - `71` shallow-eval rows
   - `6` live/implemented

docs/repo_portfolio_unified_consolidation_and_init_prompt_v6_3.md

@@ -11,6 +11,7 @@ This document supersedes earlier v6.1/v6.2 init prompts.
 - LICENSETRACKING.MD
 - ROADMAP.MD
 - SKILLS.MD
+- HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md
 - HT_REPO_INCORPORATION_AUDIT_2026-05-11.md
 - HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md
 - HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md
@@ -30,6 +31,7 @@ Rules:
 - HyperTwist currently has `71` shallow-eval rows but only `6` verified live/implemented rows in checked Unreal surfaces.
 - Of those `6`, `5` are permissive `MIT` lanes and `1` is the restrictive `onionhoney/roux-trainers` lane that is already properly clean-roomed and implemented.
 - Treat the remaining `65` HyperTwist rows as repo-evaluation backlog until the reset schedule says otherwise.
+- Use the `2026-05-12` reconciliation doc when you need the current cross-location restart authority order or the explicit post-`Phase 1R` sequence.
 
 Read in order:
 1. AGENTS.MD
@@ -38,11 +40,12 @@ Read in order:
 4. ROADMAP.MD
 5. API.MD
 6. LICENSETRACKING.MD
-7. HT_REPO_INCORPORATION_AUDIT_2026-05-11.md
-8. HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md
-9. HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md
-10. SKILLS.MD
-11. workbook sheets 00_START_HERE, 01_AUTHORITY_ORDER, 02_MODEL_BOOTSTRAP
-12. relevant repo row(s)
+7. HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md
+8. HT_REPO_INCORPORATION_AUDIT_2026-05-11.md
+9. HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md
+10. HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md
+11. SKILLS.MD
+12. workbook sheets 00_START_HERE, 01_AUTHORITY_ORDER, 02_MODEL_BOOTSTRAP
+13. relevant repo row(s)
 
 Return deltas, not blanket rewrites.

docs/repo_portfolio_unified_v6_3_README.txt

@@ -5,6 +5,7 @@ Here is what each document or folder is for, in plain English.
 Before using the v6.3 workbook or CSVs, also read:
 
 * `docs/HT_REPO_INCORPORATION_AUDIT_2026-05-11.md`
+* `docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md`
 * `docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md`
 * `docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md`
 
@@ -20,6 +21,7 @@ Interpretation rule:
 
 * `integrate`, `repurpose`, `locked strategic donor`, `donor bench`, and similar labels are **portfolio posture**
 * they are not identical to `already implemented`
+* old parse-side `Phase 4` continuation notes are lineage, not restart authority for the remaining donor portfolio
 
 The repo-row boards now carry additional 2026-05-11 columns to help keep that distinction visible:
 

docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md

@@ -24,7 +24,8 @@ Next sequence:
 1. preserve the six landed lanes
 2. run `Phase 0R` repo deep source integration evaluation for the remaining `65`
 3. run `Phase 1R` contract and handoff overhaul
-4. only then reopen broader implementation waves
+4. run `Phase 2R` retained-set ratification and packet design
+5. only then reopen broader implementation waves
 
 ## Suggested repo structure
 
@@ -50,14 +51,18 @@ Next sequence:
 1. preserve and document landed implementation truth
 2. repo deep source integration evaluation reset for remaining rows
 3. contract / handoff / provenance overhaul
-4. simulation core expansion from retained set
-5. state and notation standardization
-6. replay and export
-7. physical recognition
-8. trainer/progression
-9. AI coach
-10. immersive hyper modes
-11. optimization and polish
+4. retained-set ratification and packet design
+5. permissive implementation waves from retained rows
+6. boundary-sensitive adapter or sidecar waves
+7. restrictive clean-room waves from retained rows
+8. simulation core expansion from retained set
+9. state and notation standardization
+10. replay and export
+11. physical recognition
+12. trainer/progression
+13. AI coach
+14. immersive hyper modes
+15. optimization and polish
 
 ## Testing
 

docs/v6_5_deep_manual_pack/HyperTwist/LICENSETRACKING.md

@@ -66,6 +66,7 @@ That means:
 
 Read together with:
 
+- `C:\HyperTwist\docs\HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md`
 - `C:\HyperTwist\docs\REPO_LICENSE_TRACKING.md`
 - `C:\HyperTwist\docs\HT_REPO_INCORPORATION_AUDIT_2026-05-11.md`
 - `C:\HyperTwist\docs\HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md`

docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md

@@ -33,6 +33,35 @@ Only after that should broader roadmap widening resume.
 - refresh clean-room and Model B boundaries
 - rebuild later implementation waves from the retained set only
 
+### Phase `2R` — retained-set ratification
+
+- freeze the post-`Phase 0R` retained set into an implementation-ready board
+- define packet classes, subsystem entry points, and ownership
+
+### Phase `3R` — permissive implementation waves
+
+- execute retained straight-permissive rows first
+- prioritize the retained architecture anchors and high-value donor lanes that can become owned capability quickly
+
+### Phase `4R` — boundary-sensitive adapter and sidecar waves
+
+- resolve the retained `MPL`, mixed-term, asset-term, enterprise-slice, and commercial-boundary rows
+- prefer bounded adapter or sidecar use where the retained posture says that is the cleaner path
+
+### Phase `5R` — restrictive clean-room waves
+
+- refresh Model A / Model B chains for retained restrictive rows
+- implement only from the refreshed clean-room handoff materials
+
+### Phase `6R` — retained-set capability widening
+
+- widen simulation, recognition, XR, and support-plane work only from the retained evaluated set
+
+### Phase `7R` — benchmark, discard, and hardening closure
+
+- close oracle/reference/discard decisions
+- tie retained benchmark rows to validation and release-hardening
+
 ## A — Alignment
 Freeze terminology, repo roles, and dual-pillar architecture.
 

docs/v6_5_deep_manual_pack/README.md

@@ -9,11 +9,11 @@ This pack expands the split v6.4 docs into a more exhaustive project-specific ma
 - Unreal Engine 5.4+, C++, Blueprints, OpenXR, and a Rust/C#/C++ backbone bias are explicit for VectorShell and HyperTwist.
 - TypeScript, Node.js, and Python are minimized in backbone planning, but not omitted where they remain the most practical choice.
 - Repo-level license truth still lives in the portfolio CSVs and top-level HyperTwist governance docs. These manuals set architecture, execution, and policy.
-- For HyperTwist specifically, do not use this pack alone to infer current live implementation truth. Read the top-level 2026-05-11 incorporation audit, reset/schedule doc, and state board first.
+- For HyperTwist specifically, do not use this pack alone to infer current live implementation truth. Read the top-level 2026-05-12 reconciliation doc, 2026-05-11 incorporation audit, reset/schedule doc, and state board first.
 
 ## Authority order
 1. `repo_portfolio_unified_v6_3.*` and companion matrices remain repo-row source of truth
-2. top-level current-state correction docs such as `HT_REPO_INCORPORATION_AUDIT_2026-05-11.md`, `HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md`, and `HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md` govern current live-truth interpretation for HyperTwist
+2. top-level current-state correction docs such as `HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md`, `HT_REPO_INCORPORATION_AUDIT_2026-05-11.md`, `HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md`, and `HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md` govern current live-truth interpretation for HyperTwist
 3. this v6.5 deep manual pack governs project-level architecture and implementation posture
 4. v6.4 and earlier project markdowns are lineage and rollback reference only