# Rust Pathway Memory — Historical Reference **Status:** Reference-only. The Go Lakehouse does NOT load these traces (per ADR-001 §1.5). This note exists so future-Go-engineer knows what the Rust era accumulated, where it lives, and why it was left in place. --- ## What was there By the time of the rewrite cutoff (commit `dcf4c9a`, 2026-04-28), the Rust pathway memory held: - **88 traces** at `/home/profit/lakehouse/data/_pathway_memory/state.json` - **11/11 successful replays** as of the most recent verification (the "probation gate crossed" signal from the lakehouse `STATE_OF_PLAY.md`) - Active scrum-cycle compounding: each scrum loop iteration appended new traces and re-ran replays against existing pathway fingerprints to preempt review prompts with "this file pattern has produced bug X before" ## Where it lives (Rust repo) ``` lakehouse/ ├── crates/vectord/src/pathway_memory.rs ← implementation ├── data/_pathway_memory/state.json ← 88 traces, JSON └── docs/DECISIONS.md ADR-021 ← matrix-correctness layer design ``` The TS-side mirror lived in `tests/real-world/scrum_master_pipeline.ts` (functions `computePathwayId`, `buildPathwayVec`). Both implementations byte-matched on bucket vectors. ## Why this matters for the Go port The pathway memory's *algorithm* is portable — 32-bucket SHA256-keyed token hash, JSON state file, replay logic. The pathway memory's *signal value* is not — those 88 traces represent months of scrum loops on Rust code, with bug fingerprints anchored to Rust file prefixes (`crates/queryd/`, `crates/vectord/`, etc.) that don't exist in the Go repo. Per ADR-001 §1.5, the Go pathway memory: 1. Reimplements the algorithm (SPEC §3.4 G3.4.B is the byte-match correctness gate). 2. Starts with zero traces. The 88 Rust traces are NOT migrated. 3. Builds its own signal over Go-era scrum cycles. ## What to do if the Go pathway memory underperforms If after Phase G3 the Go pathway memory shows a noticeable lift deficit vs. the Rust era's "11/11 successful replays" baseline: 1. **First** — verify the Go algorithm byte-matches the Rust one on the SPEC G3.4.B golden input. If yes, the algorithm is correct and the gap is data-volume, not implementation. 2. **Second** — the Rust traces exist; if needed, re-prefix file paths from `crates/queryd/` style to `cmd/queryd/` style, run a compatibility check, and seed the Go pathway memory selectively. But only after the algorithm is proven byte-match correct. 3. **Third** — accept that the first ~3 months of Go scrum cycles need to rebuild the signal naturally. This is the cost of the clean restart per ADR-001 §1.5. ## Historical baseline (frozen reference) | Metric | Rust value at cutoff | Source | |---|---|---| | Total traces | 88 | `data/_pathway_memory/state.json` | | Successful replays | 11/11 | scrum loop log circa 2026-04-26 | | Distinct file prefixes | TBD — query the state file | n/a | | Distinct semantic_flag variants used | 9 (per ADR-021) | `pathway_memory.rs` | | Distinct bug_fingerprint hashes | TBD | `pathway_memory.rs` | When the Go pathway memory reaches comparable numbers, it has caught up to the Rust era and can be considered fully replacement-grade.