builder fix for kohen Day-3 FAIL: image arch, azazel co-residence, runbook drift

ROOT CAUSE (kohen Day-3 escalation):
None of the four Dockerfiles pinned --platform. Build on Apple Silicon
shipped arm64-only images to a registry consumed by amd64 SKS nodes.
Init container failed exec format error before producing logs.

DOCKERFILE FIX (defense in depth):
Pin --platform=linux/amd64 on every FROM line in all four Dockerfiles.
The build artifact now self-corrects regardless of build host.

AZAZEL CO-RESIDENCE (anomaly the kohen flagged):
Azazel L3 migration shipped (20260428…create_azazel_records.exs) but
no separate container existed. Reading the code: azazel_processor is
imported by korban_processor.external_offering at runtime in the same
Python process — not a separate process. Dockerfile.korban_processor
now COPYs azazel_processor/src/ alongside korban_processor.
Documented in the Dockerfile (AZAZEL CO-RESIDENT section) and in
deployment.yaml. Both containers (vav-pipeline + korban-processor)
now mount the shared tmp-shorashim volume so the Python→Elixir file
bridge (azazel_ingest.ex polls /tmp/shorashim/azazel/pending_l3/)
works end-to-end.

CANONICAL BUILD/PUSH (scripts/build_and_push.sh):
- Pins linux/amd64 by default; PLATFORMS env for multi-arch
- Pre-flight checks (repo root, buildx, registry login)
- Builds and pushes all four images with one command
- Closes the gap KOHEN_PROMPT.md gate 0i would otherwise leave open

KOHEN.md DRIFT (kohen recorded these as anomalies through Day 1-3):
- Line 58 hash fragment 99bbd07a…0a0187b → 99bbd07a…4ea377 (correct)
- Inheritance table: "Not yet created" claims rewritten as
  "Verify before assuming" — a prior partial setup may have left
  state, and the kohen prompt requires verifying not assuming
- L1 PV row: marked NOT REQUIRED (L1 baked into images)
- §Day 3a ConfigMap recipe marked vestigial (kept as comment)
- §Day 3b: removed manna-volume.yaml from kubectl apply list
  (deployment uses emptyDir; PVC is for a future move)
- §Day 3c: "5 containers" → "4 containers + 1 init"
- §Day 3 fail-mode list expanded with the four most common causes,
  in order, including exec format error → gate 0i

KOHEN_PROMPT.md:
- Gate 0f corrected to four images (talmudic-engine is image #3;
  azazel is co-resident in korban-processor not a separate image)
- Gate 0i added: image-architecture vs node-architecture verification
  before Day 1, with kubectl one-liner and docker manifest inspect
  per image. Drift handler in the gates section: 0i FAIL → escalate
  to builder, do not begin Day 1.

NO SPEC FILES TOUCHED:
Doorpost.verify_identity() still :ok — none of these files are in
@spec_files. No atomic spec+hash commit needed.

NEXT STEP FOR THE KOHEN:
Once these images are rebuilt and pushed via scripts/build_and_push.sh
(by anyone with the Harbor CLI secret + a working docker daemon),
restart from Day 1. Existing DB role shorashim_app, ALTER DEFAULT
PRIVILEGES, rotated DATABASE_URL, shorashim-config, and shorashim-
registry secret all remain valid across the restart.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

deploy/docker/Dockerfile.korban_processor

@@ -1,24 +1,37 @@
 # 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 python:3.12.2-slim AS build
+FROM --platform=linux/amd64 python:3.12.2-slim AS build
 
 WORKDIR /app
 
 # Install build deps
 RUN pip install --no-cache-dir poetry-core
 
-# Copy project files
+# 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
 RUN pip install --no-cache-dir pydantic==2.6.1 httpx==0.27.0 pyswip==0.2.10 hebrew-tokenizer==2.3.0
 
 # === RUNTIME STAGE ===
-FROM python:3.12.2-slim
+FROM --platform=linux/amd64 python:3.12.2-slim
 
 RUN useradd --create-home --shell /bin/bash shorashim
 USER shorashim
@@ -28,6 +41,8 @@ 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

deploy/docker/Dockerfile.shoresh_engine

@@ -1,9 +1,12 @@
 # Shorashim Shoresh Engine — Haskell root activation engine
 # Construction spec §1.1: GHC 9.6.4, Cabal 3.10
 # Communicates with vav_pipeline via Erlang Port (stdin/stdout)
+#
+# PLATFORM PIN: see Dockerfile.vav_pipeline for the rationale.
+# Exoscale SKS = amd64; arm64 images cannot exec on the cluster.
 
 # === BUILD STAGE ===
-FROM haskell:9.6.4-slim AS build
+FROM --platform=linux/amd64 haskell:9.6.4-slim AS build
 
 # haskell:9.6.4-slim is Debian Buster (EOL) — use archive repos
 RUN sed -i 's|deb.debian.org/debian|archive.debian.org/debian|g' /etc/apt/sources.list && \
@@ -26,7 +29,7 @@ RUN cabal build && \
     cp $(cabal list-bin shoresh-engine) /usr/local/bin/shoresh-engine
 
 # === RUNTIME STAGE ===
-FROM ubuntu:jammy-20240125
+FROM --platform=linux/amd64 ubuntu:jammy-20240125
 
 RUN apt-get update && \
     apt-get install -y --no-install-recommends \

deploy/docker/Dockerfile.talmudic_engine

@@ -1,9 +1,12 @@
 # Shorashim Talmudic Engine — SWI-Prolog dialectical reasoning
 # Construction spec §1.1: SWI-Prolog 9.2.2
 # Communicates with vav_pipeline via Unix domain socket
+#
+# PLATFORM PIN: see Dockerfile.vav_pipeline for the rationale.
+# Exoscale SKS = amd64; arm64 images cannot exec on the cluster.
 
 # === BUILD STAGE ===
-FROM swipl:9.2.2 AS build
+FROM --platform=linux/amd64 swipl:9.2.2 AS build
 
 WORKDIR /app
 COPY talmudic_engine/ ./
@@ -12,7 +15,7 @@ COPY talmudic_engine/ ./
 RUN swipl -g "consult('src/main'),halt(0)" -t "halt(1)"
 
 # === RUNTIME STAGE ===
-FROM swipl:9.2.2
+FROM --platform=linux/amd64 swipl:9.2.2
 
 RUN useradd --create-home --shell /bin/bash shorashim
 USER shorashim

deploy/docker/Dockerfile.vav_pipeline

@@ -1,9 +1,18 @@
 # Shorashim Vav Pipeline — Elixir/OTP release with Sanhedrin
 # Construction spec §1.1: Elixir 1.16.1, OTP 26.2.1
 # The pipeline and Sanhedrin run in the same BEAM VM.
+#
+# PLATFORM PIN:
+# Both FROM directives below pin `--platform=linux/amd64`. Exoscale
+# SKS nodes are amd64; without this pin, a build on an Apple Silicon
+# workstation would emit an arm64 image that the cluster cannot exec
+# (the kohen's Day 3 fails with "exec format error"). The pin makes
+# the build artifact self-correct regardless of build host.
+# Local multi-arch dev (linux/amd64,linux/arm64) is supported by
+# scripts/build_and_push.sh — see that script for the canonical build.
 
 # === BUILD STAGE ===
-FROM hexpm/elixir:1.16.1-erlang-26.2.1-ubuntu-jammy-20240125 AS build
+FROM --platform=linux/amd64 hexpm/elixir:1.16.1-erlang-26.2.1-ubuntu-jammy-20240125 AS build
 
 RUN apt-get update && apt-get install -y git && rm -rf /var/lib/apt/lists/*
 
@@ -28,7 +37,7 @@ RUN mix local.hex --force && \
 RUN mix release
 
 # === RUNTIME STAGE ===
-FROM ubuntu:jammy-20240125
+FROM --platform=linux/amd64 ubuntu:jammy-20240125
 
 RUN apt-get update && \
     apt-get install -y --no-install-recommends \

deploy/k8s/deployment.yaml

@@ -117,8 +117,17 @@ spec:
               cpu: "500m"
 
         # === KORBAN PROCESSOR (sidecar) ===
+        # Korban_processor imports azazel_processor (the disposal
+        # channel) in the same Python process. The Python side writes
+        # AzazelRecord JSON files to /tmp/shorashim/azazel/pending_l3/;
+        # vav-pipeline's AzazelIngest GenServer watches that directory
+        # and ingests into L3. Both containers must mount the shared
+        # tmp-shorashim volume for the file bridge to work.
         - name: korban-processor
           image: exo.container-registry.com/the-recognition-protocol/korban-processor:latest
+          volumeMounts:
+            - name: tmp-shorashim
+              mountPath: /tmp
           resources:
             requests:
               memory: "128Mi"