scriptoriumadmin/hypertwist
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
hypertwist/docs/repo_portfolio_unified_v6_3_README.txt
axiomlogicnexus 68a56e6cb8 Close HyperTwist Phase 3R packet 3R-F
2026-05-13 18:45:28 +02:00

765 lines
20 KiB
Text
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Here is what each document or folder is for, in plain English.
## 2026-05-11 current-state correction
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`
Why this matters:
* the v6.3 pack is excellent at repo selection, donor posture, and legal/architectural strategy
* it is **not** by itself a proof of current live implementation state
* HyperTwist currently has `71` shallow-eval rows, with `14` currently verified live repos in checked `UnrealHyperTwist` surfaces
* `13` of those `14` are permissive lanes
* `1` of those `14` is the restrictive `onionhoney/roux-trainers` lane, which remains the only currently verified restrictive repo that was properly clean-roomed and then implemented
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:
* `v6_3_live_state_2026_05_11`
* `v6_3_reset_lane_2026_05_11`
* `v6_3_reset_next_step_2026_05_11`
Use those columns when you need:
* current implementation truth
* reset scheduling
* the correct next repo-by-repo evaluation or implementation action
Use `docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md` when you need the same truth in one readable 71-row board rather than piecing it together from separate CSVs.
## The core v6.3 portfolio files
These are the **main portfolio-control documents**. They are the closest thing to your master decision system.
### `repo_portfolio_unified_v6_3_README.txt`
This is the **front door** to the v6.3 pack.
Its job is to explain:
* what the v6.3 pack is
* which files inside it are authoritative
* how the files relate to each other
* what changed from earlier versions
* how to use the pack without getting lost
In plain English: this is the **orientation sheet**.
A model or human should read this first before touching the other files.
---
### `repo_portfolio_unified_branch_seed_prompt_v6_3.md`
This is the **bootstrapping prompt for new threads, new models, or crashed sessions**.
Its purpose is to give a fresh model enough context to re-enter the project without hallucinating a new architecture. It tells the model:
* what the projects are
* what the authority order is
* what the repo portfolio is for
* how to think about inclusion, merger, donor logic, copy-left, and implementation posture
* what not to do
In plain English: this is the **relaunch prompt**.
When you open a new model session, this is one of the best files to feed it first.
---
### `repo_portfolio_unified_consolidation_and_init_prompt_v6_3.md`
This is the **canonical summary + initialization guide** for the whole portfolio.
It is slightly different from the branch seed prompt.
The branch seed prompt is more about **starting a fresh reasoning session**.
The consolidation/init prompt is more about **putting the whole universe in one coherent frame**.
Its purpose is to:
* summarize the final project posture
* preserve important architectural corrections and overrides
* explain how the portfolio should be interpreted
* give a model a stable conceptual map before it starts repo work
In plain English: this is the **canonical worldview file**.
It tells a model what the portfolio means.
---
### `repo_portfolio_unified_cluster_narratives_v6_3.csv`
This file groups repos into **families or clusters** and explains them in prose.
Instead of looking at repos one by one, this file helps you see:
* which repos belong to the same ecosystem
* which repos are all solving related problems
* which families matter to which project
* how the families differ internally
Examples of cluster types:
* platform/orchestration/observability
* security/recon/offensive-defensive
* reverse-engineering/SRE
* puzzle/hypercube/simulation
* research/editor/corpus/workspace
In plain English: this is the **family-level explanation file**.
It helps you understand the repo universe in chunks instead of one repo at a time.
---
### `repo_portfolio_unified_merger_matrix_v6_3.csv`
This is the **repo combination and synergy file**.
Its purpose is to answer:
* which repo should be foundation
* which repo should be donor
* which repos should be merged conceptually
* which repo upgrades another
* which repo should replace another
* which repo is only useful in combination with another
It is specifically about **composite software futures**:
* foundation repo + feature donor
* engine repo + UI donor
* sidecar repo + native core
* graph repo + visualization donor
* security engine + spatial runtime
* editor surface + research engine
In plain English: this is the **“what combines with what” file**.
It is not mainly about whether a repo is good alone. It is about what it becomes when combined.
---
### `repo_portfolio_unified_re_layer_matrix_v6_3.csv`
This is the **reverse-engineering and binary-analysis special layer file**.
It exists because the RE/SRE family became important enough that it needed its own focused matrix.
Its purpose is to organize tools like:
* Ghidra
* Rizin
* Cutter
* radare2
* ImHex
* angr
* RetDec
* Frida
* Capstone / Keystone / Unicorn / LIEF
* dnSpy / ILSpy and related tools
It also preserves the **Stratum 1–4 model**:
* Stratum 1: analyst surfaces
* Stratum 2: automation engines
* Stratum 3: primitive libraries
* Stratum 4: glue / companions
In plain English: this is the **serious RE-layer planning file**.
It tells you how binary-analysis tools fit into VectorShell and related workflows.
---
### `repo_portfolio_unified_copyleft_strategy_matrix_v6_3.csv`
This is the **license strategy and incorporation-mode file**.
Its purpose is not just to tell you a repo license.
It tells you what to **do** about the license.
For each relevant repo, it tries to capture:
* whether copy-left matters
* whether to incorporate as-is
* whether to keep it as a bounded sidecar
* whether to reverse engineer / clean-room reimplement
* whether it should be pattern-only
* why that choice makes sense
This is the file that encodes the philosophy you explicitly agreed to:
* GPL/AGPL are not exclusion filters
* reverse engineering is not automatically mandatory
* direct incorporation is not automatically best
* the correct answer is repo-by-repo
In plain English: this is the **“how to use copyleft repos intelligently” file**.
With the 2026-05-11 columns added, it also becomes one of the quickest ways to tell:
* which restrictive rows are still only pending clean-room work
* which rows are benchmark-only or discard candidates
* that `onionhoney/roux-trainers` is the only currently verified landed restrictive clean-room lane
---
### `repo_portfolio_unified_vscode_packets_v6_3.csv`
This is one of the most practically useful files.
It contains **repo-specific inspection packets** intended for coding models in VS Code or similar environments.
Its purpose is to tell a source-inspecting model:
* what repo to inspect
* what to look for
* what hidden value might be inside
* what questions need answering
* what the likely integration paths are
* what would upgrade or downgrade the repo after source inspection
In plain English: this is the **source-audit handoff file**.
It turns the portfolio into executable repo-by-repo inspection tasks.
---
### `repo_portfolio_unified_source_audit_v6_3.csv`
This is the **repo audit campaign file**.
It is broader than the VS Code packets file.
Its purpose is to organize:
* which repos should be audited first
* which ones are P0, P1, P2, P3 style priorities
* which ones matter most immediately
* which ones can wait
* what kind of audit each repo needs
If the VS Code packets are the **repo-level briefing cards**, this source audit file is the **campaign map**.
In plain English: this is the **priority and sequencing file for real repo inspection**.
After the 2026-05-11 correction, treat this file as:
* the source-audit campaign map
* plus the repo reset lane board for the remaining `57` not-yet-live HyperTwist rows
---
### `repo_portfolio_unified_phase_g_v6_3.csv`
This is the **high-level adjudication board**.
This is where a repo gets its current broad portfolio decision, such as:
* locked foundation
* locked parallel foundation
* locked strategic donor
* donor bench
* merge bench
* reserve bench
* comparator / legacy
* exclude current horizon
* integrated product surface
* implemented pattern source
It is the most useful file when you want the answer to:
* where does this repo currently stand?
* how important is it?
* which project does it belong to?
* what broad bucket is it in?
In plain English: this is the **final classification board**.
After the 2026-05-11 correction, it is the final classification board **plus** a current live-state correction board.
---
### `repo_portfolio_unified_operational_v6_3.csv`
This is the **detailed working board**.
If the Phase G file gives the big judgment, the operational file explains the **practical meaning** of that judgment.
It usually contains richer detail around:
* what the repo actually contributes
* how it could be integrated
* what “repurpose” means in practice
* whether it is direct, moderate modification, heavy modification, architecture-only, or concept-only
* implementation implications
* execution priority
* portfolio priority
In plain English: this is the **“how to actually use the repo” file**.
After the 2026-05-11 correction, it is also the best file for:
* current next-step interpretation
* whether a row is already landed, queued for permissive implementation, queued for clean-room, or better treated as benchmark/discard
---
### `repo_portfolio_unified_v6_3.xlsx`
This is the **human-friendly workbook version** of the portfolio.
Its job is not to replace the CSVs.
Its job is to make the whole system easier to browse.
Usually its purpose is:
* let you open the portfolio in a spreadsheet interface
* inspect the major boards without manually stitching CSVs together
* hand a model or human a more navigable summary artifact
* provide sheets that point to the more detailed data
In plain English: this is the **spreadsheet doorway into the portfolio**.
---
## The narrative companion bundles
These are not the master adjudication files.
They are the **prose interpretation layers**.
They turn the portfolio from spreadsheets into readable narrative.
---
### `vectorshell_narrative_bundle_v1`
This folder contains the **VectorShell narrative companion**.
It includes:
#### `VectorShell_Volume_0.md`
This is the **preface and rules volume** for VectorShell.
Its purpose is to explain:
* what the VectorShell narrative bundle is
* what authority order it follows
* what collapse rules were applied
* what VectorShell’s active posture is
* how to interpret the rest of the bundle
In plain English: this is the **intro and interpretation frame**.
#### `VectorShell_Volume_1.md`
This is the **main VectorShell repo narrative volume**.
It contains the repos that are primarily VectorShell-first:
* foundations
* core donors
* primary candidates
* main runtime and security/RE-adjacent components
In plain English: this is the **main story of which repos matter directly to VectorShell**.
#### `VectorShell_Volume_4.md`
This is the **cross-project and adjacent-use volume for VectorShell**.
It contains repos that are:
* not primarily VectorShell repos
* but still useful to VectorShell
* or transferable to it
* or useful as reserve, comparator, donor, or adjacent tools
In plain English: this is the **extended universe around VectorShell**.
---
### `hypertwist_narrative_bundle_v1`
This folder contains the **HyperTwist narrative companion**.
It includes:
#### `HyperTwist_Volume_0.md`
The HyperTwist preface and rules volume.
It explains:
* how to read the HyperTwist repo narratives
* what the active architecture posture is
* what the dual-pillar structure is
* what authority order governs the bundle
In plain English: the **interpretive intro for HyperTwist**.
#### `HyperTwist_Volume_2.md`
This is the **main HyperTwist repo narrative volume**.
It contains repos that are primarily HyperTwist-first:
* simulation foundations
* CV and recognition layers
* replay and training systems
* coaching layers
* hypercube-related foundations
In plain English: this is the **main HyperTwist repo story**.
#### `HyperTwist_Volume_4.md`
This is the **cross-project and adjacent-use volume for HyperTwist**.
It includes repos that are:
* not primarily HyperTwist-first
* but could donate value to HyperTwist
* or are reserve/comparator/cross-project relevant
In plain English: this is the **broader HyperTwist ecosystem layer**.
---
### `scriptoriumai_narrative_bundle_v1`
This folder contains the **ScriptoriumAI narrative companion**.
It includes:
#### `ScriptoriumAI_Volume_0.md`
This is the preface/rules volume for ScriptoriumAI.
Its job is to explain:
* that ScriptoriumAI is treated as largely completed
* that latest high-value repo integrations are the focus
* that forward planning is Claude Prism–anchored
* that the bundle follows v6.3 truth plus later corrections
In plain English: this is the **interpretive framing document** for ScriptoriumAI.
#### `ScriptoriumAI_Volume_3.md`
This is the **main ScriptoriumAI repo narrative volume**.
It contains repos that are primarily ScriptoriumAI-first:
* editor/workspace/corpus/research/diagram/media/memory/publishing candidates
* implemented surface parallels
* latest integration candidates
In plain English: this is the **main ScriptoriumAI repo story**.
#### `ScriptoriumAI_Volume_4.md`
This is the **cross-project and adjacent-use volume for ScriptoriumAI**.
It contains repos that are not primarily ScriptoriumAI-first but still have:
* transfer value
* donor value
* reserve value
* comparator value
* adjacent ecosystem value
In plain English: this is the **extended ScriptoriumAI ecosystem layer**.
---
## The deep manual pack
### `v6_5_deep_manual_pack`
This is the **project-specific deep guidance layer**.
It is not a repo-by-repo portfolio.
It is the **architectural, strategic, and implementation manual layer** for the three projects.
It exists because the cross-project markdowns were becoming too mixed together.
Inside it, each project has its own full manual set.
---
### `v6_5_deep_manual_pack/README.md`
This is the **master explanation of the v6.5 manual pack**.
It tells you:
* what the pack is for
* what corrections it preserves
* how it relates to v6.3
* what its authority level is
* what the project folders contain
In plain English: this is the **intro page for the deep manual pack**.
---
## Inside each project folder in `v6_5_deep_manual_pack`
Each project has the same file structure, but the meaning is project-specific.
---
### `AGENTS.md`
This is the **execution and behavioral guide** for models or engineers working on that specific project.
It explains:
* what the project really is
* what must not be confused
* what the authority order is
* how to think when making decisions
* what the hard directives are
* what a coding model should and should not do
In plain English: this is the **project operating doctrine**.
---
### `SKILLS.md`
This is the **competency and work-product guide**.
It explains:
* what kind of skills a coding model needs for that project
* what kinds of outputs it should produce
* what kinds of repo analyses are expected
* what the relevant technical literacies are
In plain English: this is the **“what a model or engineer must be good at for this project” file**.
---
### `ARCHITECTURE.md`
This is the **project architecture vision and system decomposition file**.
It explains:
* the project’s identity
* runtime center
* subsystem model
* language posture
* service boundaries
* how the whole system should be assembled
* what belongs in the backbone and what does not
In plain English: this is the **high-level system design file**.
---
### `API.md`
This is the **interface and service-boundary file**.
It explains:
* what kinds of APIs the project should expose
* what the main API families are
* what belongs in runtime vs service layer
* what the transport posture is
* how to think about interface design for that project
In plain English: this is the **service contract and boundary philosophy file**.
---
### `DEVELOPMENT.md`
This is the **implementation workflow file**.
It explains:
* how development should proceed
* suggested repo layout
* phase order
* testing expectations
* migration posture
* coding-model handoff logic
* build philosophy
In plain English: this is the **how-to-build-the-project file**.
---
### `PRD.md`
This is the **product requirements / product definition file**.
It explains:
* what the product is
* who it is for
* what problems it solves
* what the main feature families are
* what success looks like
* what the product’s promise is
In plain English: this is the **“what product are we actually making?” file**.
---
### `LICENSETRACKING.md`
This is the **project-level license strategy file**.
It does not usually replace the row-level truth in the portfolio CSVs.
Instead, it explains the **license decision framework** for that project:
* as-is
* sidecar
* reverse engineer
* pattern-only
* what to watch
* what needs review
In plain English: this is the **project’s license and incorporation policy file**.
---
### `ROADMAP.md`
This is the **project phase and milestone file**.
It explains:
* what order major work should happen in
* what the milestones are
* what each phase means
* what should be frozen first
* what gets implemented next
In plain English: this is the **project sequencing file**.
---
## How all of these fit together
Here is the simplest way to think about the whole set:
### Layer 1 — master portfolio truth
These are the files that decide **what each repo is** and **how it currently stands**:
* `phase_g`
* `operational`
* `source_audit`
* `vscode_packets`
* `copyleft_strategy`
* `re_layer`
* `merger_matrix`
* `cluster_narratives`
This layer answers:
* what repo is this
* how important is it
* what project is it for
* how should it be used
* what should be audited first
---
### Layer 2 — narrative interpretation
These are the narrative bundles:
* `vectorshell_narrative_bundle_v1`
* `hypertwist_narrative_bundle_v1`
* `scriptoriumai_narrative_bundle_v1`
This layer answers:
* what does the portfolio mean in readable prose
* what is the story of the repos for each project
* what is core vs adjacent
---
### Layer 3 — project manuals
This is the `v6_5_deep_manual_pack`.
This layer answers:
* what is the architecture of each project
* how should it be built
* what is the product
* how should licenses be handled
* how should work be sequenced
---
## If you want the shortest practical summary
### Use these first when a model starts fresh
* `repo_portfolio_unified_v6_3_README.txt`
* `repo_portfolio_unified_branch_seed_prompt_v6_3.md`
* `repo_portfolio_unified_consolidation_and_init_prompt_v6_3.md`
### Use these to decide what a repo is
* `repo_portfolio_unified_phase_g_v6_3.csv`
* `repo_portfolio_unified_operational_v6_3.csv`
### Use these to inspect source repos in VS Code
* `repo_portfolio_unified_source_audit_v6_3.csv`
* `repo_portfolio_unified_vscode_packets_v6_3.csv`
### Use these to reason about combinations and licensing
* `repo_portfolio_unified_merger_matrix_v6_3.csv`
* `repo_portfolio_unified_copyleft_strategy_matrix_v6_3.csv`
* `repo_portfolio_unified_re_layer_matrix_v6_3.csv`
### Use these to think in prose by project
* the three narrative bundle folders
### Use these to build the projects
* `v6_5_deep_manual_pack/*`
---
Meta
v6.3 & v6.5 Final Source of Truth Pack
Date: 2026-04-21
Core data counts:
{
"operational_rows": 13603,
"phase_g_rows": 13603,
"source_audit_rows": 13571,
"vscode_packets_rows": 313,
"merger_rows": 36361,
"cluster_rows": 35,
"copyleft_rows": 13603,
"re_rows": 50
}
Recommended use:
1. Freeze v6.3 & v6.5 as canonical source of truth.
2. Use other models only as secondary source-audit contributors after they read the v6.3 docs.
3. Generate narrative companion volumes from v6.3 & v6.5, not from older packs.
Reference in a new issue View git blame Copy permalink