Heimdall took CultLib as file:../CultLib/packages/*, a sibling checkout
outside this repository. Nothing pinned which CultLib a given Heimdall
commit was built against, and a sealed source could not reach it. The
deploy manifest worked around this by cloning CultLib separately to
/srv/build/CultLib with cultlib_commit=5cefa0db hardcoded in shell -- the
pin existed, it just lived in an untyped place where no build could see it.
vendor/CultLib is now a submodule pinned at exactly 5cefa0db, the commit
the manifest already used, so this change is purely structural: the
dependency does not move. Bumping to a current CultLib is a separate
change, and should be, or a failure could not be attributed.
This also uncovered that the build was never reproducible from a clean
checkout. The sibling directory had dist/ present because someone had
built it by hand at some point; a fresh CultLib clone has none, and the
packages' main/types point straight at dist/. Building Heimdall against a
fresh CultLib fails with thirteen TS2307s. The manifest knew -- it runs
npm ci then npm run build for cultcache-ts, cultnet-ts and cultmesh-ts
before touching Heimdall -- but that knowledge lived only in the shell
script. It belongs in the recipe's steps, which is where it goes next.
Verified end to end on a fresh submodule clone: the three CultLib packages
build, pnpm install resolves, tsc exits 0, dist/src/index.js is produced
(the exact path heimdall.service runs), and vitest passes 38 tests in 9
files.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
