Document mirror governance corrections
This commit is contained in:
axiomlogicnexus
parent
f311b65f84
commit
319c6463eb
3 changed files with 193 additions and 0 deletions
|
|
@ -209,6 +209,33 @@ Ad hoc clone folders are not the authority.
|
|||
|
||||
The manifest is.
|
||||
|
||||
## Current governance correction note
|
||||
|
||||
The roadmap-expansion source-exposed audit added one important operating warning:
|
||||
|
||||
- mirror separation is in place
|
||||
- clean-room handoff discipline is in place
|
||||
- but manifest parity can still lag behind actual active restrictive lanes
|
||||
|
||||
Current HyperTwist examples that should be kept visible in governance discussions:
|
||||
|
||||
- `kash/cubedesk`
|
||||
- `onionhoney/roux-trainers`
|
||||
- `cs0x7f/cstimer`
|
||||
- `efrantar/rob-twophase`
|
||||
|
||||
Implication:
|
||||
|
||||
- the mirror workspace can be legally and operationally well-structured while still suffering from control-plane drift if active restrictive mirrors are not represented consistently enough in `repos.manifest.json`
|
||||
|
||||
Practical rule:
|
||||
|
||||
- when a restrictive mirror becomes:
|
||||
- an active clean-room candidate
|
||||
- an active benchmark oracle
|
||||
- or a roadmap-visible future lane
|
||||
- update the manifest and the governance docs together rather than relying on mirror presence alone
|
||||
|
||||
## Manifest schema
|
||||
|
||||
Current schema version:
|
||||
|
|
@ -563,6 +590,7 @@ If VectorShell later needs a broad mirror fleet, the same permissive/restrictive
|
|||
6. Produce repo-specific `Model A` handoff docs for clean-room candidates.
|
||||
7. Use restrictive benchmark repos as oracles where needed, but do not confuse that with implementation approval.
|
||||
8. Re-run the workspace script after changing manifest defaults or project file maps.
|
||||
9. When source-exposed planning finds active mirror/manifest drift, treat that as a governance task before widening implementation lanes.
|
||||
|
||||
## What this setup does not do
|
||||
|
||||
|
|
@ -589,4 +617,5 @@ If another model picks this up later, the key facts are:
|
|||
- `clean-room-specs\` is the safe handoff zone
|
||||
- `implementation-workspaces\model-b\` is the isolated implementation zone
|
||||
- benchmark oracles and clean-room candidates must not be conflated
|
||||
- manifest parity matters as much as folder placement once active restrictive lanes are in use
|
||||
- large future repo fleets should go to `C:\Workspaces\<Product>\mirrors`, not into the product repos themselves
|
||||
|
|
|
|||
87
docs/HYPERTWIST_ROADMAP_OVERHAUL_EXPANSION_GUIDE.md
Normal file
87
docs/HYPERTWIST_ROADMAP_OVERHAUL_EXPANSION_GUIDE.md
Normal file
|
|
@ -0,0 +1,87 @@
|
|||
# HyperTwist roadmap overhaul and expansion guide
|
||||
|
||||
Created on `2026-04-26`
|
||||
|
||||
Purpose:
|
||||
|
||||
- preserve the roadmap-overhaul decision inside the product repo docs root
|
||||
- make the current planning call visible without needing chat context
|
||||
- point future planning models or human reviewers to the richer workbook and parse-side planning pack
|
||||
|
||||
## Product-level call
|
||||
|
||||
The original HyperTwist roadmap is still valuable.
|
||||
|
||||
It should remain preserved as the intent and lineage baseline.
|
||||
|
||||
It should not remain the sole live execution authority.
|
||||
|
||||
## Why this changed
|
||||
|
||||
HyperTwist now has real owned implementation in the Unreal-centered backend across:
|
||||
|
||||
- training
|
||||
- replay
|
||||
- recognition integration
|
||||
- coaching
|
||||
- queueing and scheduling
|
||||
- timing and analytics
|
||||
- clean-room governance
|
||||
|
||||
That means the product has outgrown a one-line-per-phase roadmap.
|
||||
|
||||
## Recommended live planning layer
|
||||
|
||||
Use five planning surfaces:
|
||||
|
||||
1. preserved historical roadmap baseline
|
||||
2. roadmap invariants
|
||||
3. live execution roadmap
|
||||
4. feature-set matrix
|
||||
5. model role and provider matrix
|
||||
|
||||
## Timing call
|
||||
|
||||
Now is a good time for the overhaul because:
|
||||
|
||||
- the backend is real enough to anchor planning
|
||||
- the repo state is clean
|
||||
- multi-model expansion has not yet been allowed to reshape architecture
|
||||
|
||||
## Main rule for model expansion
|
||||
|
||||
Define roles first.
|
||||
|
||||
Evaluate providers second.
|
||||
|
||||
Integrate providers only after the roles and feature-set map exist.
|
||||
|
||||
Current correction call from the source-exposed audit:
|
||||
|
||||
- preserve the roadmap direction
|
||||
- update the canonical planning docs so they reflect:
|
||||
- the reconciled `14`-family feature set
|
||||
- manifest and custody governance gaps
|
||||
- pre-Phase-5 speech governance gates
|
||||
- retained benchmark-oracle and mirror-intake reservations
|
||||
|
||||
## Higher-detail planning references
|
||||
|
||||
For the fuller planning pack, read:
|
||||
|
||||
- `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\92-hypertwist-roadmap-overhaul-planning-layer.md`
|
||||
- `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\93-hypertwist-roadmap-overhaul-document-map.md`
|
||||
- `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\94-hypertwist-roadmap-overhaul-model-prompts.md`
|
||||
- `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\95-hypertwist-roadmap-invariants.md`
|
||||
- `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\96-hypertwist-live-execution-roadmap.md`
|
||||
- `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\97-hypertwist-feature-set-matrix.md`
|
||||
- `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\98-hypertwist-model-role-and-provider-matrix.md`
|
||||
- `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\99-hypertwist-roadmap-expansion-established-insights.md`
|
||||
- `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\roadmap-overhaul-pack\outputs\abc-phase-2-reconciled-roadmap-expansion.md`
|
||||
- `C:\visual_studio_solutions\multi_project\GPT 5.4 HyperTwist parse\roadmap-overhaul-pack\outputs\source-exposed-audit-reconciled.md`
|
||||
- `C:\Workspaces\HyperTwist\implementation-workspaces\scratch\roadmap-bootstrap\docs\architecture\roadmap-overhaul-and-expansion-readiness.md`
|
||||
- `C:\Workspaces\HyperTwist\implementation-workspaces\scratch\roadmap-bootstrap\docs\architecture\roadmap-expansion-pack-checkpoint.md`
|
||||
|
||||
## Safety rule
|
||||
|
||||
This overhaul should stay documentation-first until the new planning layer is accepted.
|
||||
|
|
@ -207,6 +207,83 @@ Approved working posture:
|
|||
- keep the mirror in restrictive custody
|
||||
- treat the repo as a clean-room strategic donor for product-subsystem extraction only
|
||||
|
||||
### `onionhoney/roux-trainers`
|
||||
|
||||
Decision date:
|
||||
|
||||
- `2026-04-27`
|
||||
|
||||
Current licensing judgment:
|
||||
|
||||
- treat as restrictive clean-room only
|
||||
- do not use directly in a proprietary HyperTwist core
|
||||
- keep in restrictive custody
|
||||
- active clean-room lane already exists through scrubbed handoff documents
|
||||
|
||||
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`
|
||||
|
||||
Approved working posture:
|
||||
|
||||
- preserve the repo as a restrictive clean-room donor only
|
||||
- do not treat the existing clean-room implementation work as permission for later direct source reuse
|
||||
- ensure future governance records keep this lane visible as an active clean-room candidate rather than an untracked restrictive mirror
|
||||
|
||||
### `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`
|
||||
|
||||
Approved working posture:
|
||||
|
||||
- do not read it into clean implementation lanes
|
||||
- use it as a benchmark and planning reference for timer UX, session flow, import/export parity, and competitive timer behavior
|
||||
- if later implementation value remains high, route it through a dedicated clean-room 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`
|
||||
|
||||
Approved working posture:
|
||||
|
||||
- use as a correctness and solver-quality reference only
|
||||
- do not expose it to clean implementation lanes
|
||||
- preserve its benchmark-oracle role explicitly in later validation and Phase `8` planning docs
|
||||
|
||||
### `HactarCE/2x2x2x2-Scrambler`
|
||||
|
||||
Decision date:
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue