From 319c6463eba433bb341b70f1dbab0504a78e73c5 Mon Sep 17 00:00:00 2001 From: axiomlogicnexus Date: Mon, 27 Apr 2026 00:26:45 +0200 Subject: [PATCH] Document mirror governance corrections --- ..._MIRROR_WORKSPACE_AND_SUBMODULE_HANDOFF.md | 29 +++++++ ...RTWIST_ROADMAP_OVERHAUL_EXPANSION_GUIDE.md | 87 +++++++++++++++++++ docs/REPO_LICENSE_TRACKING.md | 77 ++++++++++++++++ 3 files changed, 193 insertions(+) create mode 100644 docs/HYPERTWIST_ROADMAP_OVERHAUL_EXPANSION_GUIDE.md diff --git a/docs/EXTERNAL_MIRROR_WORKSPACE_AND_SUBMODULE_HANDOFF.md b/docs/EXTERNAL_MIRROR_WORKSPACE_AND_SUBMODULE_HANDOFF.md index 244c3bb..abc149f 100644 --- a/docs/EXTERNAL_MIRROR_WORKSPACE_AND_SUBMODULE_HANDOFF.md +++ b/docs/EXTERNAL_MIRROR_WORKSPACE_AND_SUBMODULE_HANDOFF.md @@ -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\\mirrors`, not into the product repos themselves diff --git a/docs/HYPERTWIST_ROADMAP_OVERHAUL_EXPANSION_GUIDE.md b/docs/HYPERTWIST_ROADMAP_OVERHAUL_EXPANSION_GUIDE.md new file mode 100644 index 0000000..df2b03a --- /dev/null +++ b/docs/HYPERTWIST_ROADMAP_OVERHAUL_EXPANSION_GUIDE.md @@ -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. diff --git a/docs/REPO_LICENSE_TRACKING.md b/docs/REPO_LICENSE_TRACKING.md index 1a24019..3f6a85b 100644 --- a/docs/REPO_LICENSE_TRACKING.md +++ b/docs/REPO_LICENSE_TRACKING.md @@ -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: