The pin audit (2026-10-04) found Construction §1 wrong in three ways.
1. §1.5's mix.exs block was not the real mix.exs.
phoenix ~> 1.7.11 was never a dependency (the API is Plug on
Bandit); `ecto` is `ecto_sql`; telemetry is transitive (locked
1.4.2, outside the stated ~> 1.2.1); bandit, plug and the sanhedrin
path dependency were missing. The block now matches mix.exs and adds
the versions mix.lock actually builds. Terumah's Elixir table
matched the wrong block and also said postgrex ~0.17.4; corrected.
2. §1.1's component table described a machine that is not the one
running. PostgreSQL 16.2 via apt → 17, managed (17.11 today).
Podman 4.9.3 → Kubernetes/containerd, managed; Podman is used
nowhere. Ubuntu 24.04.1 → what each image is in fact built on
(Ubuntu 22.04 for pipeline and engine, Debian 12 for korban and
talmudic) and the managed node (24.04). rebar3 3.23.0 → 3.22.0, the
version in the build image. Azazel Processor added as a component.
The spec is corrected to the deployment, not the reverse.
3. §1.1's rule — "No >=. No +. No ranges." — was not true of the spec's
own Elixir deps, and "lock files are committed" was not true of two
components. Both halves fixed:
- The rule now says what is the case: a manifest may give a range;
the committed lock is the pin; every image is built from its
lock; base images are pinned by tag; managed services are pinned
to a major version and patched by the provider.
- And the build was made to obey it. The Korban image installed
three packages named by hand and let pip pick every transitive
one on the day of the build, plus an unpinned poetry-core. It now
installs the lock's main group by exact version AND hash
(scripts/lock_to_requirements.py; --require-hashes --no-deps;
pip check). The image holds the lock's 12 packages and nothing
else.
- azazel_processor/poetry.lock: generated (it had none).
- kushya_generator/pyproject.toml + poetry.lock: the four §1.4 pins
(llama-cpp-python 0.2.55, peft 0.9.0, transformers 4.38.2,
datasets 2.17.1) were pinned nowhere in the repo. They are now
declared and locked (74 packages). The lock resolves; it has NOT
been installed or run — Step 21 is unbuilt and needs a GPU.
Its test config gains the korban and azazel source paths, which
the external backend needs: 3 tests there had been failing since
the azazel build, unnoticed because that suite is in no total.
Doorpost @expected_hash 39b66c31… → 1cd07079…, in this commit, with the
witnessed file that moved it (vayakhel).
Read before committing: Elixir 474/0 (seeds 0, 42) · korban 222 passed
1 skipped and azazel 125 passed, each with dependencies installed from
its lock by hash · kushya 17 passed (was 14 of 17) · korban image
starts, imports korban_processor + azazel_processor, pip check clean ·
pipeline image reports specification_identity verified 1cd07079….
Left as written: architecture §2's technology table still names
Phoenix, PostgreSQL 16, Ubuntu 24.04 and rootless Podman for Sanhedrin
isolation, and terumah §B still lists systemd, squashfs, Caddy,
nftables for a self-hosted server. Those describe a design, not a pin.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Construction §1.3 is headed "Haskell Dependencies (Exact)" and shows an
excerpt of cabal.project.freeze. Six of its nine versions were not the
ones in the committed freeze file:
aeson 2.2.1.0 → 2.2.3.0
vector 0.13.1.0 → 0.13.2.0
bytestring 0.12.1.0 → 0.12.2.0
filepath 1.4.200.1 → 1.4.301.0
directory 1.3.8.4 → 1.3.10.1
hspec 2.11.7 → 2.11.16
base 4.18.2.0, containers 0.6.7 and text 2.0.2 already agreed. The
freeze file has not changed since Phase 1 (ae78ed2) and every engine
image has been built from it; the build plan inside the build image
(dist-newstyle/cache/plan.json, GHC 9.6.4) lists exactly these nine
versions. The spec is corrected to the freeze, not the freeze to the
spec: the freeze is the tested vessel.
- specs/shorashim_vayakhel.md §1.3: the six versions.
- specs/shorashim_terumah.md §D: the same, plus rows for filepath and
directory; bytestring was marked "ships with GHC" — GHC 9.6.4 ships
0.11.5.3, and the freeze pins a newer one from Hackage.
- Doorpost @expected_hash 5094e48e… → 39b66c31…, in this commit, with
the witnessed file that moved it (vayakhel).
Read before committing: Elixir 474/0 on seeds 0 and 42; the built
pipeline image reports specification_identity verified 39b66c31….
No engine change: the engine image is untouched.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Architecture §3.1 said the Shoresh Engine "encodes the ~500 Biblical
Hebrew triliteral roots", its file tree called Lexicon.hs "the ~500
roots with entries", and terumah §E2 listed a "~500 roots" lexicon as
material still to be consolidated (~1-2 weeks).
Since tablet 34 the roots are read, and can be counted. L1 carries
1,378: 1,243 roots under which Brown-Driver-Briggs files a lemma, and
135 words that stand alone under no root. 1,263 are triliteral, 32 have
two letters, 83 have four or more. And the engine does not hold a list
of them — it reads them from L1 (Shoresh.Lexicon, Shoresh.Roots).
- specs/shorashim_architecture.md §3.1: the Purpose sentence says where
the roots come from and how many there are; the Lexicon.hs line in
the file tree likewise.
- specs/shorashim_terumah.md §E2: the root lexicon is in hand (✅) —
the OSHB Hebrew Lexicon is exactly the BDB + Strong's consolidation
the row was waiting for; moved from "need to acquire" to "in hand".
- Doorpost @expected_hash 2f40c382… → 094b8164…, in this commit, with
the witnessed file that moved it (architecture).
Read before committing: Elixir 461/0 on 11 of 12 runs (seed 0 ×6 and
six other seeds). One run of seed 0 reported a single failure that was
not captured and did not recur in eleven further runs; unidentified,
recorded in the build log. Pipeline image reports
specification_identity verified 094b8164… and l1_hash pass.
Left as written, and no longer true of the build: §3.1's data
structures still type a root as exactly three consonants, and its file
tree still lists data/roots.json and data/torah_refs.json, which do
not exist — the roots live in L1.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Architecture §3.5 listed a Python-Prolog FFI among the Korban
Processor's dependencies ("swipl-ffi (or pyswip)"); Construction §1.4
and terumah pinned pyswip. It was declared, installed in every image,
and never imported. The Korban Processor does not call Prolog: haktarah
emits Prolog-format STRINGS, and the pipeline carries them to the
Talmudic Engine over its Unix socket (Construction §3.3). The korban
image has no libswipl, so the package could not have been used there
had anything tried. Tablet 35 corrected its version; the transmitter's
word is to remove it.
Removed from:
- specs/shorashim_architecture.md §3.5 requirements
- specs/shorashim_vayakhel.md §1.4
- specs/shorashim_terumah.md (materials row; the compatibility-testing
line now names hebrew-tokenizer alone)
- BUILD_KORBAN.md
- korban_processor/pyproject.toml, poetry.lock (regenerated)
- deploy/docker/Dockerfile.korban_processor
Doorpost @expected_hash 81da49d4… → 2f40c382…, in this commit, with the
three witnessed files that moved it (architecture, vayakhel,
BUILD_KORBAN).
Read before committing: Elixir 461/0 (seeds 0, 42); korban 222 passed,
1 skipped against the installed package with pyswip absent; korban
image starts and idles as before; vav-pipeline image reports
specification_identity verified 2f40c382… and l1_hash pass.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Construction §1.4 pinned `pyswip = "0.2.11"`. PyPI has 0.2.10 (2020) and
then 0.3.0; 0.2.11 does not exist and never did. pyproject.toml copied
the spec faithfully, so `pip install .` in korban_processor has failed
since Step 13. Nobody saw it: the Dockerfile installs its dependencies
by hand and already said 0.2.10, and the test run uses PYTHONPATH. The
pin was wrong in the one place that was never executed. Found
2026-10-04, the first time the korban suite was run from a clean
container by installing the package.
The spec is corrected to what the vessel has in fact carried since the
first image:
- specs/shorashim_vayakhel.md §1.4, BUILD_KORBAN.md, terumah §row:
0.2.11 → 0.2.10. Terumah now also says what is true of this
material: declared and installed, not imported anywhere, and not
usable in the korban image as built (no libswipl) — it must be
tested against SWI-Prolog 9.2.2 before first use.
- korban_processor/pyproject.toml: 0.2.10. `pip install .` succeeds in
python:3.12.2-slim; 222 passed, 1 skipped against the installed
package.
- korban_processor/poetry.lock: regenerated (poetry 2.5.1). It had
never contained pyswip, httpx or hebrew-tokenizer at all.
- Doorpost @expected_hash: ed2a6aec… → 81da49d4…, in this commit, with
the two witnessed files that moved it (vayakhel, BUILD_KORBAN), per
the Doorpost's own rule and the precedent of 0572a2c (postgrex).
No behaviour changes: the image installs the same four packages it
installed yesterday.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Each spec corresponds to a parshah of Shemot. The earlier names
were generic English (materials, operations, construction,
economic_model). Torah names them precisely:
- Shemot 25:2 — terumah (תרומה, root רום, "what is lifted")
- Shemot 27:20 — tamid (תמיד, "continual" — the lamp that never goes out)
- Shemot 35:1 — vayakhel (קהל, "assembled" — community-formed building)
- Shemot 38:21 — pekudei (פקד, "accounted" — every material counted)
Renames:
shorashim_materials.md → shorashim_terumah.md
shorashim_operations.md → shorashim_tamid.md
shorashim_construction.md → shorashim_vayakhel.md
shorashim_economic_model.md → shorashim_pekudei.md
Updated cross-references in:
- README.md (parshah table + repo tree, also fixed stale tree
showing src/ and transcripts/ that no longer exist)
- AGENTS.md
- BUILD_KORBAN.md
- specs/shorashim_terumah.md (internal Document Registry)
Generic English is silver. Torah's words are gold (Mishlei 25:11).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
