# HyperTwist Phase 5R Clean-Room Prompt And Handoff Packet

Created on `2026-05-14`

Update on `2026-05-18`:

- `cubing/alg.js` is closed for its accepted bounded sequence
- `HactarCE/2x2x2x2-Scrambler` is closed for its accepted bounded sequence
- `cubing/twisty.js` is closed for its accepted bounded sequence
- the active restrictive phase packet remains `Phase 5R-A`
- the current next live restrictive repo inside that packet is `kash/cubedesk`
- the active per-repo execution file is `0400-kash-cubedesk.clean-room-prompt-sequence.md`

Update on `2026-05-27`:

- `kash/cubedesk` is no longer the default next live restrictive repo
- the row is already partially landed through bounded publication /
  entitlement and local social challenge slices
- any future `kash/cubedesk` widening now requires repo-local reconciliation
  against the corrected `KubeTimr` / `cstimer` / `qqTimer` hierarchy before a
  new bound is reopened
- `0400-kash-cubedesk.clean-room-prompt-sequence.md` remains the canonical
  per-repo route file when such a reopening is explicitly selected

## Status

This document is now the canonical `Phase 5R` clean-room prompt, operator, and
restart packet for HyperTwist.

It records:

- the current restrictive-lane execution topology after `Phase 4R-F`
- the exact per-repo prompt-pack files
- the current primer rule
- the repo-local consolidation route
- the optional shared cross-lane checkpoint route
- the bounded clean implementation route
- the restart-safe handoff prompt for a new instance

This packet does not reopen broad repo evaluation.

It operationalizes the already-closed evaluation and routing work.

It also must not be misread as product-surface proof.

## Current project state

Current truth:

- broad repo evaluation is closed through `Phase 0R`
- retained-set and ownership routing is closed through `Phase 2R`
- permissive and boundary-sensitive implementation is closed through `Phase 4R-F`
- the active restrictive phase packet remains `Phase 5R-A`
- `cubing/alg.js`, `HactarCE/2x2x2x2-Scrambler`, and `cubing/twisty.js` are already closed inside that packet
- `kash/cubedesk` is no longer the automatic next live restrictive repo
- any future `kash/cubedesk` widening is reopened-later only and must pass
  repo-local reconciliation first

That means the next restrictive work, if any later reopening is explicitly
selected, is:

1. source-exposed `Model A` refresh and strengthening per restrictive repo
2. clean `Model B` contributor passes per restrictive repo
3. repo-local clean `Model B` consolidation per restrictive repo
4. bounded clean implementation one repo and one bound at a time
5. shared cross-lane reconciliation only when a repo-local consolidated note still flags real overlap

Reconciliation rule:

- repo-local and shared reconciliation are additive passes, not reset passes
- they must account for all qualifying prior clean notes and any existing standing reconciled notes in scope
- they must not silently omit earlier valid effort; any rejection, supersession, or deferral must be named with rationale
- those dispositions must also be printed in the task summary for the pass, or the summary must explicitly say that no such omission/disposition occurred

Bounded implementation rule:

- one bounded implementation run equals one bound
- after each bounded run, the next route must be chosen explicitly:
  - same bound again
  - next bound
  - rerun repo-local consolidation if the standing map is too thin or stale
  - optional targeted cross-lane checkpoint only if the standing note or
    just-finished bound closeout explicitly says it is needed before the next
    bound
  - owner-scoped validation-unblock packet only if validation is blocked by a
    broader first-party issue outside the lane owner surface
- do not pre-authorize donor-lane-wide multi-bound widening in a single pass

It does not mean:

- reopen broad `0R` evaluation
- let clean `Model B` infer from restrictive mirrors
- run a single source-exposed thread across all four raw restrictive repos
- run one giant multi-repo bounded implementation pass

It also does not mean:

- bookmark presence equals retained status
- queue presence equals merit
- sequence-file presence equals implementation
- prompt-pack presence equals landed product truth

## 2026-05-14 coordinator doctrine note

For this packet, keep the following states separate:

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

This packet means:

- the four restrictive rows are already selected retained clean-room candidates with active routing
- the four rows are queued for explicit `Model A` and `Model B` clean-room work
- clean-room routing is the required route discipline, not a statement that these lanes are technically weaker than permissive alternatives

This packet does not mean:

- those rows are already implemented
- those rows outrank stronger owners outside their approved lanes
- those rows became product truth merely by being listed here

If one of these rows is the strongest owner inside its bounded lane, the correct result is:

- preserve that owner verdict
- keep raw restrictive source away from clean `Model B`
- route realization through the clean-room stack

Canonical doctrine docs:

- [HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md:1)
- [HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md:1)

## Restrictive repos in current scope

The active four-repo restrictive queue is:

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

Original full recommended execution order was:

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

Current remaining live order is:

1. `kash/cubedesk`

Reason:

- `cubing/alg.js` sets semantic ownership first
- `cubing/twisty.js` is adjacent and should not outrun the semantic lane
- `HactarCE/2x2x2x2-Scrambler` is narrow and isolated
- `kash/cubedesk` is broad and benefits from stronger upstream first-party
  contract clarity before bounded implementation begins

## Canonical prompt-pack files

Per-repo sequence files:

- `C:\Workspaces\HyperTwist\clean-room-specs\0100-cubing-alg-js.clean-room-prompt-sequence.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\0200-cubing-twisty-js.clean-room-prompt-sequence.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\0300-hactarce-2x2x2x2-scrambler.clean-room-prompt-sequence.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\0400-kash-cubedesk.clean-room-prompt-sequence.md`

Shared clean consolidation prompt:

- `C:\Workspaces\HyperTwist\clean-room-specs\0500-phase5r-restrictive-lanes.model-b-consolidation-prompt.md`

Shared operator packet:

- `C:\Workspaces\HyperTwist\clean-room-specs\0600-phase5r-clean-room-operator-sequence-and-handoff.md`

## Thread topology

Source-exposed `Model A`:

- one repo per source-exposed thread
- do not combine multiple raw restrictive repos in one source-exposed
  conversation
- may read the repo mirror and the source-backed restrictive dossier for that
  same repo
- must write or strengthen the scrubbed `Model A` handoff

Clean `Model B` contributor:

- one repo per clean contributor thread
- primer first
- contribution prompt second
- both in the same clean conversation
- must not read restrictive mirrors or source-backed restrictive dossiers

Clean `Model B` consolidation:

- by default one fresh clean repo-local thread per repo
- no primer by default
- starts directly from the repo-local consolidation prompt inside the repo's
  sequence file
- reads the repo's scrubbed `Model A` handoff plus that repo's clean `Model B`
  staged notes
- may continue directly into the first bounded implementation pass for that
  same repo if the conversation stayed clean, the standing reconciled note is
  written first, and the repo and bound are explicitly selected before coding

Shared optional clean `Model B` cross-lane reconciliation:

- by default one fresh clean thread only when needed
- no primer by default
- starts directly from the shared `0500` prompt
- reads only the affected repos' handoffs, standing reconciled notes, and
  staged clean notes
- must account for all qualifying prior clean notes and standing reconciled
  notes for the lanes in scope
- must not silently drop earlier valid effort; any supersession or deferral
  must be explicit
- may continue directly into the first bounded implementation pass for one
  explicitly selected affected repo if the checkpoint concludes that
  implementation may proceed and the conversation stayed clean

Clean `Model B` bounded implementation:

- begins either in one fresh clean thread or as an immediate continuation from
  the same repo's clean consolidation thread or targeted checkpoint thread
- one repo at a time
- one bound at a time
- no primer by default
- consumes the repo-specific reconciled note and, only if one was explicitly
  created for that lane, the shared cross-lane reconciled note
- safest route is to review after each closed bound and start a fresh clean
  conversation for the next bound
- lower-friction route may reuse the same clean bounded implementation
  conversation for the immediately next bound only after the prior result has
  been reviewed and the next bound has been explicitly selected
- the clean coordinating instance may serve as consolidation instance and
  immediate implementation instance if it has remained clean and has not been
  source-exposed
- if that already-open bounded implementation thread was initialized from the
  clean prompt and no contrary evidence exists, a continuation prompt may
  assume cleanliness and say `continue in this same clean Model B bounded
  implementation thread`
- if the thread is known to have become source-exposed, it must not continue
  as the clean implementation thread

## Primer rule

Primer first is required by default only for:

- clean `Model B` contributor threads

Primer first is not required by default for:

- source-exposed `Model A` threads
- the shared clean consolidation thread
- the clean bounded implementation thread

The primer is a context-loading and workflow-selection prompt.

It is not the controlling output contract for contribution, consolidation, or
bounded implementation.

## Current Phase 5R sequencing rule

Default operator flow:

1. run one restrictive repo at a time
2. complete `Model A`
3. complete clean `Model B` primer and contribution
4. complete repo-local consolidation for that repo
5. implement that repo one bound at a time
   - safest route: open a fresh clean bounded implementation conversation
   - lower-friction route: let the same clean consolidation or targeted
     checkpoint conversation continue directly into the first bounded
     implementation pass for that repo

After each bounded run, stop and choose the next route explicitly rather than
auto-continuing into additional bounds.

Shared cross-lane reconciliation is not the default next move.

Use it only when the repo-local consolidated note still says a real owner-boundary
or shared-contract overlap needs explicit coordination before implementation.

That repo-local or shared reconciliation pass must account for all qualifying
prior clean notes in scope and must not silently omit earlier valid effort.

It must also surface any omission, exclusion, supersession, narrowing, or
deferral in the task summary for that pass.

## Repo-specific lanes and current boundaries

### `cubing/alg.js`

Primary retained lane:

- algorithm-language semantics
- parsing
- structured representation
- traversal and transformation
- validation profiles
- keyboard and share/interchange helpers

Boundary:

- do not let it collapse into `cubing/cubing.js` custody
- do not let it widen into viewer, player, or runtime ownership

### `cubing/twisty.js`

Primary retained lane:

- compact viewer/player behavior
- replay controls
- scrubber and cursor semantics
- embedded player shell
- visualization shell

Boundary:

- do not let it displace `cubing/cubing.js` classic semantics
- do not let it displace `Hyperspeedcube` hyper runtime ownership

### `HactarCE/2x2x2x2-Scrambler`

Primary retained lane:

- narrow Melinda `2x2x2x2` state/move/random-state/debug semantics

Boundary:

- keep this lane narrow
- do not widen it into a general runtime, trainer shell, or hyper foundation

### `kash/cubedesk`

Primary retained lane:

- selective subsystem extraction only
- trainer-session coupling above the existing first-party timer substrate
- timer-modal drill-session composition
- session domain
- analytics
- integrated smart-cube workflow composition
- local persistence
- profile/public progression
- entitlement and gated features
- social/challenge support

Boundary:

- do not recreate the whole CubeDesk product shell
- do not displace `KubeTimr`, `qbr`, `Hyperspeedcube`, or the current
  first-party training stack
- keep the licensing contradiction explicit in `Model A` custody

## Required clean outputs

Each source-exposed `Model A` pass should leave:

- a strengthened repo-specific scrubbed `Model A` handoff
- optionally a staged `Model A` safe review note under
  `C:\Workspaces\HyperTwist\clean-room-specs\outputs`

Each clean `Model B` contributor pass should leave:

- one staged repo-specific contribution note under
  `C:\Workspaces\HyperTwist\clean-room-specs\outputs`

The shared clean consolidation pass should leave:

- `C:\Workspaces\HyperTwist\clean-room-specs\outputs\phase5r-restrictive-lanes.model-b-reconciled.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\outputs\cubing-alg-js.model-b-reconciled.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\outputs\cubing-twisty-js.model-b-reconciled.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\outputs\hactarce-2x2x2x2-scrambler.model-b-reconciled.md`
- `C:\Workspaces\HyperTwist\clean-room-specs\outputs\kash-cubedesk.model-b-reconciled.md`

Each bounded implementation pass should leave:

- one staged repo-specific bound note updated in place for that pass

## Clean-source boundary reminder

For clean `Model B`:

- allowed safe roots are defined in `MODEL_B_SOURCE_ACCESS_BOUNDARY.md`
- the repo-specific sequence files under `clean-room-specs` are allowed
- the scrubbed `Model A` handoffs under `clean-room-specs` are allowed
- the repo mirrors under `C:\Workspaces\HyperTwist\mirrors\restrictive\*` are forbidden
- the source-backed restrictive dossiers under
  `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\42-46-*.md`
  are forbidden

## New-instance restart order

If a new instance must take over the active `Phase 5R` packet:

1. read this document
2. read `C:\HyperTwist\docs\MODEL_B_SOURCE_ACCESS_BOUNDARY.md`
3. read `C:\Workspaces\HyperTwist\clean-room-specs\0600-phase5r-clean-room-operator-sequence-and-handoff.md`
4. read the repo-specific sequence file for the lane being worked
5. if taking over a source-exposed pass, use the repo-specific `Model A` prompt
6. if taking over a clean contributor pass, use the repo-specific primer first
   and then the repo-specific contribution prompt in the same thread
7. if taking over the shared consolidation pass, do not run the primer; start
   from the shared `0500` prompt
8. if taking over bounded implementation, do not run the primer; start from
   the repo-specific bounded implementation prompt

## Copy-paste handoff prompt

Use the following prompt if this thread is unavailable and a new instance must
continue the current packet:

```text
You are continuing HyperTwist at the current Phase 5R clean-room packet.

Do not restart broad repo evaluation.

Current project truth:

- Phase 0R evaluation is already closed
- Phase 1R retained-set contract is already closed
- Phase 2R ownership routing is already closed
- permissive and boundary-sensitive implementation is already closed through Phase 4R-F
- the active restrictive phase packet remains Phase 5R-A
- cubing/alg.js is already closed inside that packet
- HactarCE/2x2x2x2-Scrambler is already closed inside that packet
- there is no default current next live restrictive repo
- kash/cubedesk may reopen only after repo-local reconciliation says a specific remaining bound is still justified

Your first operating references are:

1. C:\HyperTwist\docs\HYPERTWIST_PHASE_5R_CLEAN_ROOM_PROMPT_AND_HANDOFF_PACKET_2026-05-14.md
2. C:\HyperTwist\docs\HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md
3. C:\HyperTwist\docs\HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md
4. C:\HyperTwist\docs\MODEL_B_SOURCE_ACCESS_BOUNDARY.md
5. C:\Workspaces\HyperTwist\clean-room-specs\0600-phase5r-clean-room-operator-sequence-and-handoff.md

Then load the current repo-specific sequence file as needed:

- C:\Workspaces\HyperTwist\clean-room-specs\0100-cubing-alg-js.clean-room-prompt-sequence.md
- C:\Workspaces\HyperTwist\clean-room-specs\0200-cubing-twisty-js.clean-room-prompt-sequence.md
- C:\Workspaces\HyperTwist\clean-room-specs\0300-hactarce-2x2x2x2-scrambler.clean-room-prompt-sequence.md
- C:\Workspaces\HyperTwist\clean-room-specs\0400-kash-cubedesk.clean-room-prompt-sequence.md

Shared consolidation prompt:

- C:\Workspaces\HyperTwist\clean-room-specs\0500-phase5r-restrictive-lanes.model-b-consolidation-prompt.md

Current remaining live restrictive repo order:

1. kash/cubedesk

Topology rules:

- one source-exposed Model A thread per restrictive repo
- one clean Model B contributor thread per restrictive repo
- contributor thread gets primer first, then contribution prompt, in the same clean conversation
- shared consolidation is one fresh clean thread and does not get the primer by default
- bounded implementation starts in one fresh clean thread per repo by default
  and does not get the primer by default
- the same clean consolidation or targeted checkpoint conversation may instead
  continue directly into the first bounded implementation pass for one repo if
  the cleanliness and explicit-decision conditions are met
- after review, the same clean implementation thread may be reused for the
  immediately next bound, but one run still equals one bound

Clean-room boundary rules:

- Model A may read the restrictive mirror and the source-backed restrictive dossier for its assigned repo
- Model B must not read the restrictive mirror
- Model B must not read the source-backed restrictive dossier
- Model B works only from scrubbed handoffs, approved clean-room docs, approved first-party docs, approved staging docs, and first-party code

Current goal:

- continue the active Phase 5R packet from the correct next step
- do not improvise a different workflow
- do not combine multiple raw restrictive repos into one source-exposed thread
- do not combine multiple bounded implementation lanes into one implementation thread

If the next step is source-exposed Model A:

- run the repo-specific Model A prompt from the correct numbered sequence file

If the next step is a clean contributor pass:

- run the repo-specific primer prompt first
- then run the repo-specific contribution prompt in the same clean conversation

If the next step is cross-lane consolidation:

- start a fresh clean conversation
- use only the shared 0500 consolidation prompt

If the next step is bounded implementation:

- either start a fresh clean conversation or continue directly from the same
  repo's clean consolidation or targeted checkpoint conversation if it stayed
  clean and the repo and bound have been explicitly selected
- use only the repo-specific bounded implementation prompt
- implement one bound only

Report the concrete next step you are taking before you start executing it.
```

## Closing rule

This packet is the current restart-safe authority for the `Phase 5R` restrictive
clean-room execution route.

If later packets supersede it, preserve this document as historical authority
and add a newer packet rather than silently erasing the execution chain.
