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.
