Scott KarpandClaude Fable 5.1
f4e8e5afc8
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>
68 lines
2.8 KiB
Docker
68 lines
2.8 KiB
Docker
# check=skip=FromPlatformFlagConstDisallowed
|
|
# ^ The --platform=linux/amd64 pins below are DELIBERATE (Exoscale SKS
|
|
# nodes are amd64). BuildKit lints a constant --platform as a smell;
|
|
# here it is the fix. Silenced so a real warning is not lost in noise.
|
|
# Shorashim Korban Processor — Python offering protocol
|
|
# Construction spec §1.1: Python 3.12.2
|
|
# Processes korbanot (model outputs) through the offering protocol
|
|
#
|
|
# PLATFORM PIN: see Dockerfile.vav_pipeline for the rationale.
|
|
# Exoscale SKS = amd64; arm64 images cannot exec on the cluster.
|
|
#
|
|
# AZAZEL CO-RESIDENT:
|
|
# Per BUILD_AZAZEL.md, azazel_processor (the disposal channel) is
|
|
# imported by korban_processor.external_offering and runs in the
|
|
# same Python process. It is NOT a separate container — the two-goat
|
|
# architecture (Vayikra 16:8) requires equal-capacity disposal in
|
|
# the SAME pool. Both sources are baked into this image.
|
|
|
|
FROM --platform=linux/amd64 python:3.12.2-slim AS build
|
|
|
|
WORKDIR /app
|
|
|
|
|
|
# Copy korban_processor
|
|
COPY korban_processor/pyproject.toml ./
|
|
COPY korban_processor/src/ src/
|
|
COPY korban_processor/test/ test/
|
|
|
|
# Copy azazel_processor source — imported by korban_processor.external_offering
|
|
COPY azazel_processor/src/azazel_processor/ src/azazel_processor/
|
|
|
|
# Install dependencies FROM THE LOCK FILE (Construction §1.1).
|
|
# Until 2026-10-04 this line named three packages by hand and let pip
|
|
# choose every transitive one on the day of the build; and an unpinned
|
|
# `pip install poetry-core` rode along into the image. The lock's main
|
|
# group is rendered to hashed requirements and installed exactly:
|
|
# --require-hashes refuses anything the lock did not record, --no-deps
|
|
# refuses anything the lock did not list.
|
|
COPY korban_processor/poetry.lock ./
|
|
COPY scripts/lock_to_requirements.py /tmp/lock_to_requirements.py
|
|
RUN python /tmp/lock_to_requirements.py poetry.lock > /tmp/requirements.txt && \
|
|
pip install --no-cache-dir --require-hashes --no-deps -r /tmp/requirements.txt && \
|
|
pip check
|
|
|
|
# === RUNTIME STAGE ===
|
|
FROM --platform=linux/amd64 python:3.12.2-slim
|
|
|
|
RUN useradd --create-home --shell /bin/bash shorashim
|
|
USER shorashim
|
|
|
|
WORKDIR /home/shorashim/korban_processor
|
|
|
|
COPY --from=build --chown=shorashim:shorashim /app/ ./
|
|
COPY --from=build /usr/local/lib/python3.12/site-packages/ /usr/local/lib/python3.12/site-packages/
|
|
|
|
# PYTHONPATH puts korban_processor first; azazel_processor is a
|
|
# sibling package under the same src/ tree (see build stage above).
|
|
ENV PYTHONPATH=/home/shorashim/korban_processor/src
|
|
|
|
# L1 Torah filesystem — baked into the image
|
|
COPY --chown=shorashim:shorashim l1/ /mnt/torah/
|
|
|
|
ENV L1_MOUNT_POINT=/mnt/torah
|
|
|
|
# The korban processor is invoked by the vav_pipeline
|
|
# In Phase 5, it will also expose an HTTP endpoint for external model integration
|
|
CMD ["python", "-m", "korban_processor"]
|