fix: repair all broken documentation links across docsite

- Fix 124 broken internal links in 27 files: ](/docs/X) → ](/X)
  (baseUrl '/trinity/docs/' + routeBasePath '/' caused double /docs/docs/ URLs)
- Fix MDX syntax errors in 9 research reports (<-> → ↔, < before text → &lt;)
- Fix escaped backticks in cycle44 report breaking code fences
- Fix 3 broken relative links in overview/introduction.md
- Fix "Get Started" button in index.tsx linking to /docs/ instead of /
- Update sidebars.ts: expand Research from 14 to 80 entries (all reports)
- Build passes with zero broken link warnings

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Author: gHashTag

docsite/docs/api/index.md

@@ -11,12 +11,12 @@ Complete API documentation for Trinity modules.
 
 | Module | Description |
 |--------|-------------|
-| [VSA](/docs/api/vsa) | Vector Symbolic Architecture |
-| [VM](/docs/api/vm) | Ternary Virtual Machine |
-| [Hybrid](/docs/api/hybrid) | HybridBigInt storage |
-| [Firebird](/docs/api/firebird) | LLM inference engine |
-| [VIBEE](/docs/api/vibee) | Specification compiler |
-| [Plugin](/docs/api/plugin) | Extension system |
+| [VSA](/api/vsa) | Vector Symbolic Architecture |
+| [VM](/api/vm) | Ternary Virtual Machine |
+| [Hybrid](/api/hybrid) | HybridBigInt storage |
+| [Firebird](/api/firebird) | LLM inference engine |
+| [VIBEE](/api/vibee) | Specification compiler |
+| [Plugin](/api/plugin) | Extension system |
 
 ## Quick Reference
 

docsite/docs/api/jit.md

@@ -4,7 +4,7 @@ sidebar_position: 9
 
 # JIT Compilation API
 
-[VSA](/docs/concepts/glossary) operations run in loops over thousands of vector elements. The JIT compiler replaces these loops with native SIMD instructions, processing 16--32 elements per CPU cycle. Result: **15--260x speedup** on hot paths. You do not need to understand JIT internals -- just create an engine and call the same operations.
+[VSA](/concepts/glossary) operations run in loops over thousands of vector elements. The JIT compiler replaces these loops with native SIMD instructions, processing 16--32 elements per CPU cycle. Result: **15--260x speedup** on hot paths. You do not need to understand JIT internals -- just create an engine and call the same operations.
 
 The JIT system compiles specialized machine code for your exact vector dimension at runtime. The first call for a given dimension compiles the function. Every subsequent call reuses the cached native code.
 
@@ -67,7 +67,7 @@ Frees all compiled functions, executable memory, and caches.
 
 #### `dotProduct(self: *JitVSAEngine, a: *HybridBigInt, b: *HybridBigInt) !i64`
 
-Computes the [dot product](/docs/concepts/glossary) of two hypervectors using JIT-compiled SIMD code. Vectors are automatically unpacked before the operation. The function compiles on first use for the given dimension and caches for reuse.
+Computes the [dot product](/concepts/glossary) of two hypervectors using JIT-compiled SIMD code. Vectors are automatically unpacked before the operation. The function compiles on first use for the given dimension and caches for reuse.
 
 ```zig
 const dot = try engine.dotProduct(&vec_a, &vec_b);
@@ -76,7 +76,7 @@ const dot = try engine.dotProduct(&vec_a, &vec_b);
 
 #### `bind(self: *JitVSAEngine, a: *HybridBigInt, b: *HybridBigInt) !void`
 
-Element-wise ternary multiplication ([binding](/docs/concepts/glossary)). **Modifies `a` in place.** The result vector `a` is marked dirty so the packed representation recomputes on next access.
+Element-wise ternary multiplication ([binding](/concepts/glossary)). **Modifies `a` in place.** The result vector `a` is marked dirty so the packed representation recomputes on next access.
 
 ```zig
 try engine.bind(&vec_a, &vec_b); // vec_a now holds the bound result
@@ -88,7 +88,7 @@ try engine.bind(&vec_a, &vec_b); // vec_a now holds the bound result
 
 #### `bundle(self: *JitVSAEngine, a: *HybridBigInt, b: *HybridBigInt) !void`
 
-Element-wise sum with ternary threshold ([bundling](/docs/concepts/glossary)). **Modifies `a` in place.** For each position: positive sum becomes `+1`, negative sum becomes `-1`, zero stays `0`.
+Element-wise sum with ternary threshold ([bundling](/concepts/glossary)). **Modifies `a` in place.** For each position: positive sum becomes `+1`, negative sum becomes `-1`, zero stays `0`.
 
 ```zig
 try engine.bundle(&vec_a, &vec_b); // vec_a now holds the bundled result

docsite/docs/api/sequence-hdc.md

@@ -6,7 +6,7 @@ sidebar_position: 8
 
 This module turns text into vectors. Feed it strings like "hello world", and it produces compact numeric vectors that capture the text's pattern. Similar texts produce similar vectors. Use it for language detection, text classification, or semantic search -- without training a neural network.
 
-Under the hood, the module uses [Hyperdimensional Computing](/docs/concepts/glossary) (HDC). It maps characters to high-dimensional [ternary vectors](/docs/concepts/glossary) (\{-1, 0, +1\}), then combines them to represent words, phrases, and documents. The key insight: texts that share character patterns produce vectors that point in similar directions.
+Under the hood, the module uses [Hyperdimensional Computing](/concepts/glossary) (HDC). It maps characters to high-dimensional [ternary vectors](/concepts/glossary) (\{-1, 0, +1\}), then combines them to represent words, phrases, and documents. The key insight: texts that share character patterns produce vectors that point in similar directions.
 
 **Source:** `src/sequence_hdc.zig`
 
@@ -22,7 +22,7 @@ graph LR
   D --> E["Compare via<br/>cosine similarity"]
 ```
 
-1. **Split** the input into overlapping character [n-grams](/docs/concepts/glossary) (e.g., trigrams).
+1. **Split** the input into overlapping character [n-grams](/concepts/glossary) (e.g., trigrams).
 2. **Encode** each n-gram by looking up character vectors and combining them.
 3. **Bundle** all n-gram vectors into a single vector using majority vote.
 4. **Compare** the result to stored vectors using cosine similarity.
@@ -103,7 +103,7 @@ The n-gram size controls how much local context each encoding captures.
 
 ## ItemMemory
 
-Maps symbol IDs (or ASCII characters) to deterministically generated random [hypervectors](/docs/concepts/glossary). Vectors are lazily created on first access and cached in a `HashMap`.
+Maps symbol IDs (or ASCII characters) to deterministically generated random [hypervectors](/concepts/glossary). Vectors are lazily created on first access and cached in a `HashMap`.
 
 Each trit in a generated vector is uniformly random from \{-1, 0, +1\}, seeded by `symbol_id * 2654435761 + seed` using the standard PRNG.
 
@@ -147,7 +147,7 @@ Encodes an entire string as an array of character hypervectors. Returns a newly
 
 ## NGramEncoder
 
-Encodes character [n-grams](/docs/concepts/glossary) using position-encoded binding. Each character in an n-gram shifts by its position index, then all characters bind together. This preserves order: "abc" and "bac" produce different vectors.
+Encodes character [n-grams](/concepts/glossary) using position-encoded binding. Each character in an n-gram shifts by its position index, then all characters bind together. This preserves order: "abc" and "bac" produce different vectors.
 
 <details>
 <summary>Encoding Formula</summary>

docsite/docs/api/sparse.md

@@ -6,7 +6,7 @@ sidebar_position: 10
 
 When most elements in your vector are zero, storing all of them wastes memory. `SparseVector` stores only the non-zero elements with their positions. For a 10,000-element vector with 90% zeros, this saves 10x memory and makes operations 10x faster.
 
-Trinity uses [ternary vectors](/docs/concepts/glossary) (\{-1, 0, +1\}). Many operations -- masking, gating, thresholding -- produce vectors dominated by zeros. `SparseVector` exploits this by keeping two sorted arrays: indices (where non-zero elements live) and values (what those elements are). All lookups use binary search. All VSA operations use merge-join algorithms that skip zeros entirely.
+Trinity uses [ternary vectors](/concepts/glossary) (\{-1, 0, +1\}). Many operations -- masking, gating, thresholding -- produce vectors dominated by zeros. `SparseVector` exploits this by keeping two sorted arrays: indices (where non-zero elements live) and values (what those elements are). All lookups use binary search. All VSA operations use merge-join algorithms that skip zeros entirely.
 
 **Source:** `src/sparse.zig`
 

docsite/docs/benchmarks/competitor-comparison.md

@@ -35,7 +35,7 @@ Trinity's CPU inference (35-52 tok/s) is usable for interactive chat. Cloud prov
 | **Trinity BitNet** | **141K-608K** | RTX 4090/L40S | Verified benchmarks |
 | bitnet.cpp (Microsoft) | 298K | RTX 3090 | I2_S kernel |
 
-These are kernel benchmark numbers measuring raw computation speed, not end-to-end text generation. See [GPU Inference Benchmarks](/docs/benchmarks/gpu-inference) for methodology.
+These are kernel benchmark numbers measuring raw computation speed, not end-to-end text generation. See [GPU Inference Benchmarks](/benchmarks/gpu-inference) for methodology.
 
 ---
 
@@ -99,4 +99,4 @@ Trinity is positioned as the **green computing leader** in LLM inference. The te
 - GPT-4/Claude: Estimated from API response times
 - All coherence verified with standard prompts (12/12 coherent responses for Trinity)
 
-See [BitNet Coherence Report](/docs/research/bitnet-report) for detailed test methodology.
+See [BitNet Coherence Report](/research/bitnet-report) for detailed test methodology.

docsite/docs/benchmarks/gpu-inference.md

@@ -19,7 +19,7 @@ BitNet b1.58 models use ternary weights (\{-1, 0, +1\}), enabling highly efficie
 The numbers above are for the BitNet b1.58-2B-4T model (2.4 billion parameters) using the bitnet.cpp inference engine with I2_S quantization. Actual throughput depends on batch size, sequence length, and system configuration.
 
 :::caution
-These throughput figures represent bitnet.cpp kernel benchmark results (measuring raw computation speed), not end-to-end text generation throughput. End-to-end generation speed is substantially lower due to sequential token generation, memory transfers, and tokenizer overhead. See the [BitNet Coherence Report](/docs/research/bitnet-report) for measured end-to-end generation speeds.
+These throughput figures represent bitnet.cpp kernel benchmark results (measuring raw computation speed), not end-to-end text generation throughput. End-to-end generation speed is substantially lower due to sequential token generation, memory transfers, and tokenizer overhead. See the [BitNet Coherence Report](/research/bitnet-report) for measured end-to-end generation speeds.
 :::
 
 ## Model Size Scaling

docsite/docs/benchmarks/index.md

@@ -33,19 +33,19 @@ Ternary \{-1, 0, +1\} weights eliminate the need for multiplication in matrix-ve
 
 ### GPU Inference
 
-BitNet b1.58 models running on consumer and datacenter GPUs achieve throughput measured in hundreds of thousands of tokens per second for small models. Performance varies by GPU type, model size, and batch configuration. See [GPU Inference Benchmarks](/docs/benchmarks/gpu-inference) for detailed numbers.
+BitNet b1.58 models running on consumer and datacenter GPUs achieve throughput measured in hundreds of thousands of tokens per second for small models. Performance varies by GPU type, model size, and batch configuration. See [GPU Inference Benchmarks](/benchmarks/gpu-inference) for detailed numbers.
 
 ### JIT Compilation
 
-Trinity includes a custom JIT compiler with backends for ARM64 (Apple Silicon, Raspberry Pi, etc.) and x86-64 (Intel/AMD). VSA operations such as bind, bundle, dot product, and permute are compiled to native machine code at runtime, with compiled functions cached for reuse. See [JIT Compilation Performance](/docs/benchmarks/jit-performance) for architecture-specific results.
+Trinity includes a custom JIT compiler with backends for ARM64 (Apple Silicon, Raspberry Pi, etc.) and x86-64 (Intel/AMD). VSA operations such as bind, bundle, dot product, and permute are compiled to native machine code at runtime, with compiled functions cached for reuse. See [JIT Compilation Performance](/benchmarks/jit-performance) for architecture-specific results.
 
 ### Memory Efficiency
 
-The framework provides multiple memory representations optimized for different use cases: HybridBigInt with lazy packed/unpacked conversion, bit-packed trit arrays, and sparse COO-format vectors for data with many zeros. A 10,000-dimensional vector that would consume 40KB in float32 fits in roughly 2.5KB using packed ternary encoding. See [Memory Efficiency](/docs/benchmarks/memory-efficiency) for a detailed breakdown.
+The framework provides multiple memory representations optimized for different use cases: HybridBigInt with lazy packed/unpacked conversion, bit-packed trit arrays, and sparse COO-format vectors for data with many zeros. A 10,000-dimensional vector that would consume 40KB in float32 fits in roughly 2.5KB using packed ternary encoding. See [Memory Efficiency](/benchmarks/memory-efficiency) for a detailed breakdown.
 
 ### Competitor Comparison
 
-How does Trinity stack up against Groq, GPT-4, and other LLM providers? Trinity offers 35-52 tok/s on CPU with self-hosted costs of $0.01-0.35/hr, compared to cloud providers charging per-token fees. See [Competitor Comparison](/docs/benchmarks/competitor-comparison) for detailed benchmarks and cost analysis.
+How does Trinity stack up against Groq, GPT-4, and other LLM providers? Trinity offers 35-52 tok/s on CPU with self-hosted costs of $0.01-0.35/hr, compared to cloud providers charging per-token fees. See [Competitor Comparison](/benchmarks/competitor-comparison) for detailed benchmarks and cost analysis.
 
 ## Ternary Arithmetic Advantage
 

docsite/docs/concepts/balanced-ternary.md

@@ -77,7 +77,7 @@ Trinity represents trits in memory using a compact **packed encoding** that stor
 
 This encoding uses 2 bits per trit, achieving an effective density of 1.585 / 2 = 79.3% of the theoretical maximum. While not perfectly optimal (the theoretical minimum is log2(3) = 1.585 bits per trit), the 2-bit encoding enables fast bitwise operations and aligns naturally with byte boundaries.
 
-The [HybridBigInt](/docs/api/hybrid) type in Trinity manages this encoding transparently. It maintains two representations: a **packed** form for memory-efficient storage and an **unpacked** form (an array of individual trit values) for fast computation. Conversions between the two are performed lazily -- only when needed -- and are cached to avoid redundant work.
+The [HybridBigInt](/api/hybrid) type in Trinity manages this encoding transparently. It maintains two representations: a **packed** form for memory-efficient storage and an **unpacked** form (an array of individual trit values) for fast computation. Conversions between the two are performed lazily -- only when needed -- and are cached to avoid redundant work.
 
 With this encoding, a 256-trit vector (a common dimension in Trinity's VSA operations) occupies just 64 bytes in packed form, compared to 256 bytes if each trit were stored in a full byte, or 1024 bytes if stored as 32-bit floats.
 
@@ -97,13 +97,13 @@ With this encoding, a 256-trit vector (a common dimension in Trinity's VSA opera
 
 The balanced ternary representation is the foundation of every subsystem in Trinity:
 
-- **VSA operations** ([bind, unbind, bundle](/docs/api/vsa)) operate element-wise on ternary vectors. Binding uses trit multiplication; unbinding is identical to binding (the operation is its own inverse for non-zero trits).
-- **BitNet inference** ([Firebird](/docs/api/firebird)) quantizes LLM weights to \{-1, 0, +1\}, turning matrix multiplications into accumulations.
-- **The Ternary VM** ([VM](/docs/api/vm)) executes bytecode with a ternary instruction set, operating on ternary stack values.
+- **VSA operations** ([bind, unbind, bundle](/api/vsa)) operate element-wise on ternary vectors. Binding uses trit multiplication; unbinding is identical to binding (the operation is its own inverse for non-zero trits).
+- **BitNet inference** ([Firebird](/api/firebird)) quantizes LLM weights to \{-1, 0, +1\}, turning matrix multiplications into accumulations.
+- **The Ternary VM** ([VM](/api/vm)) executes bytecode with a ternary instruction set, operating on ternary stack values.
 
 ## Further Reading
 
-- [Ternary Computing Concepts](/docs/concepts) -- overview and motivation
-- [The Trinity Identity](/docs/concepts/trinity-identity) -- why the golden ratio connects to base-3
-- [VSA API Reference](/docs/api/vsa) -- ternary vector operations
-- [HybridBigInt API Reference](/docs/api/hybrid) -- packed trit storage
+- [Ternary Computing Concepts](/concepts) -- overview and motivation
+- [The Trinity Identity](/concepts/trinity-identity) -- why the golden ratio connects to base-3
+- [VSA API Reference](/api/vsa) -- ternary vector operations
+- [HybridBigInt API Reference](/api/hybrid) -- packed trit storage