specs §1.1/§1.5 + Doorpost: the pins say what is built, and the build obeys them

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>

vav_pipeline/lib/vav_pipeline/doorpost.ex

@@ -175,7 +175,7 @@ defmodule VavPipeline.Doorpost do
   # changes; the update is a deliberate operator commit. A bare
   # hash-update commit (without a corresponding spec change in the
   # same commit) is itself a drift signal.
-  @expected_hash "39b66c3156d58fee5d0790008db4a542f90ed3007786a7c8b646edeb75e2f80e"
+  @expected_hash "1cd070792fc101c5a526680cf8a8116d586151b969a1ba2cf3924e5f02d3cc40"
 
   @doc "Return the list of files that constitute the category-grade specification."
   @spec files() :: [String.t()]