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

Activity

1. gHashTag commented on Aug 13, 2026

   

   gHashTag

   on Aug 13, 2026

   OwnerAuthor

   More actions

   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
2. gHashTag commented on Aug 13, 2026

   

   gHashTag

   on Aug 13, 2026

   OwnerAuthor

   More actions

   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
3. gHashTag commented on Aug 13, 2026

   

   gHashTag

   on Aug 13, 2026

   OwnerAuthor

   More actions

   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 = "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/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
4. gHashTag commented on Sep 11, 2026

   

   gHashTag

   on Sep 11, 2026

   OwnerAuthor

   More actions

   Rechecked against current main at 03ae2f93f5af2fd4fa23e4c613a3c0e19ac51530 on 2026-09-12.

   Closing the original diagnosis as not planned/invalid, following the author's explicit retraction in #737 (comment). The current build obtains VSA from zig_hdc; the manifest pins zig-hdc to b73b2fa29874f4e30297f167a6ea8a3c2ded9d32 and zig-golden-float to e7ce32885de2a8c50b7b6a3030d0592202145dd1, so the moving-main archive problem described in that comment is also no longer present.

   This does not certify the entire build. Current test-target failures and a pipeline that swallows their exit code are tracked in #616. See https://github.com/gHashTag/trinity/actions/runs/34614355939; the test logs, rather than the green job summary, contain the failure evidence.
5. gHashTag

   closed this as not plannedon Sep 11, 2026