Build & Test is red on main: the VSA module was deleted but two build targets still reference it

[gHashTag]

Build & Test has been failing on main since the refactor. The cause is not CI configuration — three source files cannot be loaded:

src/hybrid.zig:1:1: error: unable to load 'hybrid.zig': FileNotFound
src/vsa.zig:1:1:    error: unable to load 'vsa.zig':    FileNotFound
src/vsa_jit.zig:1:1: error: unable to load 'vsa_jit.zig': FileNotFound

What was measured

42490a222 "refactor: remove 4425 lines of migrated duplicates (#517)" deleted src/vsa.zig — a 130-line facade re-exporting vsa/common.zig, vsa/core.zig, vsa/encoding.zig, vsa/agent.zig, vsa/concurrency.zig, vsa/hrr.zig, vsa/storage.zig, vsa/tests.zig.

The whole src/vsa/ tree went with it — all eight targets are gone, and src/vsa.zig exists nowhere else in the tree, including the zig-golden-float submodule. build.zig:2377 already carries the note "VSA module … REMOVED", so the removal was intended.

Two references were left behind.

The two references are not equivalent

build.zig:188 — vsa_tests. Tests for a module that no longer exists. Nothing consumes it. Removing it is unambiguous.

build.zig:1150 — vsa_tri. This one has live consumers. Its own comment says:

// VSA module for TRI (moved up: needed by tvc_corpus_mod and fluent CLI)

So tvc_corpus_mod and the fluent CLI currently depend on a module whose source is gone. This is not a leftover — it is a live dependency that the refactor broke.

The decision this needs

Where should vsa_tri now come from? Deleting it removes whatever tvc_corpus and the fluent CLI use it for; pointing it at some other implementation risks linking a different VSA than the one those call sites were written against. external/zig-golden-float/src/ has vsa_jit.zig and src/ternary/hybrid.zig, but no vsa.zig.

That is a call for whoever performed the migration. I have deliberately not guessed it.

Separately fixed

The goto-bus/setup-zig 404 in two workflows — #736. Unrelated to this.

🤖 Generated with Claude Code

[gHashTag]

The repository already answers this. build.zig.zon:5-9:

"src/vsa.zig and the 27 files of src/vsa/ were extracted here in 42490a2. build.zig kept building modules from the old path; this is the half that never landed."

I opened this asking where vsa should come from. The migration's own manifest says: zig-hdc. Four independent probes then established what still stands between that and a green build.

The extraction is byte-exact — and incomplete

crates/trios-hdc/vendor/zig-hdc/:

src/vsa.zig	byte-identical to the deleted file (diff silent)
all 27 files under src/vsa/	byte-identical, 27 identical / 0 differing
src/vsa/agent/	absent — autonomous.zig, memory.zig, system.zig, types.zig, unified.zig

agent.zig imports all five. It backs 16 of the 59 exports — UnifiedAgent, AgentMemory, AutonomousAgent, ImprovementLoop, UnifiedAutonomousSystem and the rest.

Three things block the repoint

1. The dependency has no hash. build.zig.zon declares .zig_hdc = .{ .url = "git+https://github.com/gHashTag/zig-hdc#main", .hash = "PLACEHOLDER" } — a literal PLACEHOLDER.
2. The vendored copy is an orphan gitlink. Mode 160000, commit 27bb44aa, no entry in .gitmodules — git submodule status fails with "no submodule mapping found". A fresh clone does not fetch it.
3. build.zig still points at the deleted path in both places, and five more missing paths sit alongside: src/vsa/photon_{demo,immersive,terminal,trinity_canvas}.zig and src/vsa/raygui_impl.c.

Correcting my own framing above

I wrote that vsa_tri has "live consumers" and implied removing it would break them. A verifier refuted that, and it is worth stating plainly: all five wirings are dangling. Two of the five receiving modules do reference the import — src/tvc/tvc_corpus.zig:16 and src/tri/tri_vsa.zig:12 — but they reference a module whose root file does not exist. That is a dangling reference, not a live need. Three of the five are dangling and never referenced.

So the choice is not "delete versus keep". Nothing works today either way.

Not a difference between candidates, but worth knowing

src/vsa.zig exports pub const LockFreePool = concurrency.LockFreePool; and concurrency.zig defines no such symbol — in the deleted original and in zig-hdc alike.

external/zig-golden-float/ is not a candidate: no aggregator, missing 4 of the 7 sibling modules, and its own src/vsa/common.zig does @import("../hybrid.zig") against a file that is not there.

What is still unverified

Whether any of this compiles. The probes were read-only by instruction and no zig build was run. The agent/ gap and LockFreePool are file-existence and grep findings; how Zig's lazy declaration analysis surfaces them is untested.

🤖 Generated with Claude Code

[gHashTag]

This is now determined by measurement, not a judgement call

I opened this saying the choice of replacement needed a human. It does not. Two measurements settle it.

The missing agent/ subdirectory blocks nothing

zig-hdc lacks src/vsa/agent/, which backs 16 of the 59 exports. Every one of those 16 was grepped across src/, crates/ and tools/, excluding the vendored copy itself:

UnifiedAgent  AgentMemory  AgentRole  Modality  MultiModalToolUse
AutonomousAgent  ImprovementLoop  UnifiedAutonomousSystem
UnifiedRequest  UnifiedResponse  SystemCapability
getUnifiedAgent  getAgentMemory  getAutonomousAgent  getUnifiedSystem

Not one is referenced anywhere. The gap is real and inert.

Everything actually used is present

The two files that genuinely import the module use seven symbols between them:

symbol	in vendor/zig-hdc/src/vsa.zig
HybridBigInt	present
TEXT_VECTOR_DIM	present
bind	present
cosineSimilarity	present
bundle2	present
HRR	present

Correcting my own first pass: it reported bundle and tri as missing. Both were artefacts of the pattern I used. vsa.bundle2 was truncated to bundle because [A-Za-z_]+ stops at a digit — the real symbol is bundle2 and it is declared at line 44. tri never was a usage; it matched the comment // @origin(spec:tri_vsa.tri).

What that leaves

Mechanical, not architectural:

1. Point the module root off b.path("src/vsa.zig") — at the vendored path, or at zig_hdc once its .hash = "PLACEHOLDER" is resolved.
2. Register crates/trios-hdc/vendor/zig-hdc in .gitmodules; today it is an orphan gitlink (160000, commit 27bb44aa) that git submodule status rejects and a fresh clone never fetches.
3. Delete vsa_tests at build.zig:188 — tests of a tree that no longer exists.

Still unverified, and stated as such: whether it compiles. No zig build was run at any point in this investigation. LockFreePool is re-exported from concurrency.zig, which defines no such symbol — in the deleted original and in zig-hdc alike, so it is pre-existing and not a difference between the options.

🤖 Generated with Claude Code

[gHashTag]

Retracting this issue: it describes a defect that main does not have

I investigated a checkout that is 84 commits behind main and wrote this up as if it were current. On origin/main:

$ git show origin/main:build.zig  | grep -c 'b.path("src/vsa.zig")'
0

There are no dangling references. build.zig takes the module from the dependency:

const zig_hdc_dep = b.dependency("zig_hdc", .{ .target = target, .optimize = optimize });
const hdc_vsa = zig_hdc_dep.module("zig-hdc-vsa");

Done in 486de2993 "Take vsa from the repository it was migrated to (#686)" and bc20dc48a "The library facade takes its core modules from where they went (#701)" — two and three days ago, before I opened this. The vsa_tests step was removed in the same pass, with a comment explaining that addTest needs a root module carrying a known target and a dependency-exported module does not.

Everything in my earlier comments about "five dangling wirings" and "the choice of replacement" was about a stale branch. The measurement that the agent/ gap is inert and that every used symbol is present still holds — it just was not the blocker.

The real cause of Build & Test on main

Same failure locally and in CI:

build.zig.zon:19:21: error: hash mismatch: manifest declares
  'golden_float-2.1.0-h7LKhZMGCwBW0FS_zsli6CWxs9d5pElRE1pFFiy3WRSD'
but the fetched package has
  'golden_float-2.1.0-h7LKhUUNCwAtKVHQ56wjridCZVwXY7_oxT2…'

It never reaches compilation. And it is structural rather than a stale value:

.url = "https://github.com/gHashTag/zig-golden-float/archive/main.tar.gz",
.hash = "golden_float-2.1.0-h7LKhZMG…",

archive/main.tar.gz is a moving target. Every commit to that repository's main changes the tarball and invalidates the pinned hash. zig_hdc is declared the same way, so it carries the same fuse — upstream main last moved 2026-08-11.

Updating the hash fixes it until the next upstream commit. Pinning each .url to a commit or tag fixes it permanently, at the cost of an explicit bump when you want the update — which is what a lockfile is for.

I have not made either change: I could not reproduce the fetched hash locally (this machine has Zig 0.16.0, the repository pins 0.15.2, and the toolchain download did not complete), so I would be writing a hash I had not computed.

Suggest closing this issue and tracking the manifest problem separately.

🤖 Generated with Claude Code