YouTube Corpus Audit

Retrieval is live again, on Brandon's go-ahead

Neither the Trash copy nor /Applications/Ollama.app existed by the time the repair ran, so there was nothing to put back. Homebrew carried the formula and began building openssl@4 from source, since Ventura on x86_64 no longer receives bottles, which placed a long compile chain ahead of ollama itself. The route that worked was the vendor's own prebuilt server tarball, ollama-darwin.tgz v0.40.11, 181,324,349 bytes, sha256 aea7d3f2e32371b7644a6e2ec8d4f26820a0e3965918cce8a46cef3e947f6291. It is a flat tree of the ollama binary beside its libggml and libllama runners, so the tree has to stay together for the runner to load. It installed to ~/.local/opt/ollama-0.40.11 with a symlink at /usr/local/bin/ollama, which also returns the ollama CLI to PATH. The old root-owned dangling symlink was kept beside it as ollama.dangling-symlink-kept-2026-10-26 rather than discarded.

Proof. The 0.24.0 server on the unlinked inode was stopped and pid 18600 now reports 0.40.11, with all six models intact across the version jump. /api/embeddings and /api/embed each return 768 dimensions, and ask.embed() returns 768. corpus_test.py reports 10 of 10 domains COVER, 100 / 100. /ask on the music question returns 20 cited results in 35.7 seconds with the vault, memory and corpus-registry layers all scoring above the 0.60 gate, against 0 results before the repair. The layer indexes were intact throughout: vault 24,604 rows, domain 2,781, memory 331, corpus 20.

It survives a reboot. ensure_ollama.py ends in a branch that runs ollama serve when the server is down, resolved off PATH, so that branch was dead for as long as the CLI was missing from PATH. Restoring the symlink reconnects it. Tested by killing the server and running the hook the way SessionStart does: it printed “started ollama serve”, pid 22825 came up on 0.40.11, an embed returned 768 dimensions, and a second run reported healthy. The test is self-authored, and it ran the real hook against a really downed server, so the next session recovers without help.

The hook that called that server healthy

ensure_ollama.py probed /api/tags with a 1 second timeout and printed “/ask embed server already up” at every session start. That is a liveness check that cannot fail the way the tool fails, so it green-lit a dead embed path. It now requests a real embedding with an 8 second budget and prints a DEGRADED warning naming the cause and the fix.

Proof, and it has now fired for real. The app was quit and this session resumed, and the hook printed the full DEGRADED warning unprompted at SessionStart, naming the lost model runner and the fix. That is an unplanned production firing rather than a fixture written for it, so the earlier “not proven in production” caveat is retired. Backup kept at ensure_ollama.py.bak-before-embed-probe-2026-10-26. The healthy-case cost is measured now as well: with the server repaired it prints “/ask embed server up and embedding.” in 0.36 s cold and 0.19 s warm, exit 0. One caveat for anyone testing it by hand, line 57 drains stdin to close the harness pipe, so run it as python3 ensure_ollama.py < /dev/null or it blocks on stdin and looks like an ollama hang.

Row floor on both index builders

normalize_indexes.py and build_lesson_index.py now route every index write through one shared write_with_row_floor(). It reads the key count already on disk, refuses to replace the file when the new pass produces fewer keys, saves the rejected output as <name>.json.rejected, keeps a .bak-<date> of the file it does replace, and exits 2. A --allow-shrink flag is the only override.

Proof. Tested against the real Trey corpus by running the real builder on 5 of its 35 summaries: all three raw indexes held at 89 / 254 / 93 keys, three .rejected files were written, exit code 2, and the corpus files came back byte-identical. Five unit cases also pass, including the exact 52 to 20 technique drop. Caveat: these tests are self-authored and the gate has still to fire on an unplanned production run.

Registry repointed and rescanned

The dead ~/Desktop/yt-iximusic path in refresh_registry.py now points at ~/New Desktop/yt-iximusic, where the 130 files actually live. The second music path was left alone because it was never missing.

Proof. The music domain went from 0 files to 189 on a live rescan dated 2026-10-26. Backups kept beside both files.

93 stale music paths resolved inside the domain index

With embedding restored, the music domain answered its own question and cited ~/Desktop/yt-iximusic/shiner_book_inserts.md, a path the offload had already killed. 93 of the 240 music rows in domain_embeddings/index.jsonl carried that dead prefix. Each was resolved to ~/New Desktop/yt-iximusic under a test stronger than basename and byte size: the row's own stored chunk text had to be found inside the replacement file.

Proof. 93 of 93 passed the text proof, 0 were flagged, and the row count held at 2,781 across the write, with a backup at index.jsonl.bak-2026-10-26. Dead music paths in the index are now 0, and the re-run cites a file that exists on disk.

disk_space_guardian.sh

Read in full: it is report-and-alert only and says so in its header. It computes df, and on LOW or CRITICAL it runs du and find and sends an ntfy alert. It contains no delete, trash or move call, and it reports staged delete/ folders by size without emptying them. Its log holds only state lines.

Verdict. Not the deleter. Its log does show the disk repeatedly reaching LOW at 16–21 GB free, which is the pressure that motivates manual sweeps.

Syncthing

No Syncthing config exists on this Mac. ~/Library/Application Support/Syncthing/config.xml and ~/.config/syncthing/config.xml are both absent, and there is no .stversions directory under the home folder, the Desktop or ~/New Desktop. It is banned and gone.

Verdict. Cannot be the current cause. It remains the documented historical suspect, with no artifact left on disk to confirm or refute it.

The 2026-06-06 Desktop offload

It is why every ~/Desktop/<X> path in older scripts and notes now misses, and why the registry reads 0 documents for music. The memory record lists Anatomy-Jams among the items it moved. Anatomy-Jams is in neither the Desktop nor ~/New Desktop today.

Verdict. Confirmed as a path-breaker. Its part in the one folder it is recorded as moving and which is now absent cannot be traced to it from any log.