scriptoriumadmin/hypertwist
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Tighten roadmap repo selection policy language

Browse source
This commit is contained in:
axiomlogicnexus 2026-05-10 00:10:47 +02:00
parent e09f3c66ee
commit 0ce8788ce5
1 changed files with 9 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
docs/HYPERTWIST_ROADMAP_OVERHAUL_EXPANSION_GUIDE.md
View file

@ -75,17 +75,22 @@ Current correction call from the source-exposed audit and current execution refr
## Donor portfolio phase taxonomy
- unrelated repos are omitted
- duplicate, inferior, redundant, or clearly superseded repos are omitted
- selected high-value permissive repos are not just inspiration; they are intended full implementation targets inside first-party HyperTwist, executed packet by packet rather than through one bulk import event
- selected high-value restrictive repos are not just archival references; they are intended clean-room implementation targets when they remain selected after portfolio triage
- donor or reference status does not by itself mean a selected repo is discarded; selected repos may still be full implementation targets, bounded donor lanes, bounded clean-room lanes, or benchmark/reference lanes depending on phase and licensing posture
- repo-portfolio intake/classification, mirror custody boundaries, model allowlists, and first-pass donor evaluation belong primarily to Phase `0` and are materially established already
- owned contract extraction from chosen donors belongs primarily to Phase `1` and is already reflected in the first-party notation, replay, training-content, provenance, vision-sidecar, and speech-sidecar contracts
- deep source-level audit of the wider donor corpus is not globally closed; it remains selective ongoing work anchored by the late-Phase-`4` manifest-reconciliation / custody-governance reservation and by later phase-specific donor decisions
- clean-room work belongs first to Phase `0` governance and Phase `1` contract shaping, then executes only for selected restrictive repos when a bounded first-party lane needs it; several restrictive donors already have scrubbed Model A handoff files, but not every restrictive mirror has or needs a full clean-room implementation yet
- implementation of valuable donor ideas is intentionally distributed by domain across later phases rather than treated as one giant repo-import pass:
- portfolio-level sorting/classification is largely done, but deep source-level audit of every still-selected repo is not globally closed; it remains ongoing work anchored by the late-Phase-`4` manifest-reconciliation / custody-governance reservation and by later phase-specific donor decisions
- clean-room work belongs first to Phase `0` governance and Phase `1` contract shaping, then continues into bounded first-party implementation for selected restrictive repos when their product lane opens; several restrictive donors already have scrubbed Model A handoff files, but not every still-selected restrictive mirror has been fully realized yet
- implementation of selected repo value is intentionally distributed by domain across later phases rather than treated as one giant repo-import pass:
- Phase `3` / `4`: coaching, runtime, orchestration, recognition continuity, and live consumers
- Phase `5`: speech-sidecar and embodied-coach donors
- Phase `6`: hypercube/simulation donors
- Phase `7`: XR/immersive donors
- Phase `8`: benchmark-oracle, correctness, and release-hardening donors
- do not treat the mirror portfolio as an instruction to deep-audit or reimplement every repo before product work can continue; only the active and justified donor lanes should be pulled forward
- do not treat the mirror portfolio as an instruction to deep-audit or reimplement every repo before product work can continue; instead, treat it as a selected execution backlog that closes over time through the first-party phase roadmap
## Current execution-reality references