TORAH ANCHOR — Shemot 40:33-34: וַיְכַל מֹשֶׁה אֶת הַמְּלָאכָה. וַיְכַס הֶעָנָן אֶת אֹהֶל מוֹעֵד וּכְבוֹד יְהוָה מָלֵא אֶת הַמִּשְׁכָּן. Vay'khal Mosheh et ham'lakhah — and THEN the cloud covered it. The work being finished and the mishkan being usable are two statements, and the second one does not follow from the first by itself. An image that builds is ham'lakhah. An image that serves is the other verse. Per BUILDER_HANDOFF_amd64.md: "You do not declare the build complete because it compiled. It is complete when it runs on the altar it was built for." ===================================================================== 1. THE SEGFAULT — diagnosed, and not where the handoff thought ===================================================================== REPRODUCED on 2026-08-23, clean tree, buildx: #16 9.162 Compiling 4 files (.ex) #16 9.880 Segmentation fault ERROR: ... exit code: 139 The handoff read this as Broken Tablet #12 resurfacing (OTP 26.2.1 segfaults; use 26.2.5.9) plus QEMU. Both halves turned out to be wrong, and the difference matters because acting on either one would have changed a pinned version for no reason: - NOT the OTP version. OTP 26.2.1 amd64 starts, JITs, and compiles fine under `docker run` on this host. Tablet #12 was about a NATIVE macOS aarch64 OTP build; this is Linux amd64 in a container. Same exit code, different bug. - NOT QEMU. This host's buildx already emulates via Rosetta, not QEMU — probed directly (grep rosetta /proc/self/maps inside the amd64 build step returns /run/rosetta/rosetta). The segfault happens under Rosetta, inside BuildKit's sandbox, and not under `docker run` with the same emulator. What actually dies is the BEAM JIT's dual W^X mapping for generated machine code, in the emulated build sandbox. The fix is the handoff's option 2 alone: deploy/docker/Dockerfile.vav_pipeline (build stage only) + ENV ERL_FLAGS="+JMsingle true" Single mapping instead of dual. Build-stage only — the shipped release runs the ordinary dual-mapping JIT on the amd64 node. before: 403m12s then Error (2026-05-13); 13.1s then Error (08-21) after: 36s, whole image, first try CONSEQUENCE FOR THE SPEC: specs/shorashim_vayakhel.md §1.1 keeps OTP 26.2.1. The pin was never the defect, so there is nothing here to fix and nothing to add. No spec file is touched by this commit and Doorpost.verify_identity() is unchanged at :ok. ===================================================================== 2. .dockerignore — the build context was carrying the host's tree ===================================================================== There was no .dockerignore. Every Dockerfile COPYs whole component directories, so each build shipped the HOST's compiled artifacts into the container and the in-container toolchain then tried to REUSE them: vav_pipeline/_build 20 MB of .beam from a DIFFERENT ERTS vav_pipeline/deps 4.7 MB shoresh-engine/dist-newstyle 129 MB of arm64 GHC objects korban_processor/.venv, **/__pycache__ First reproduction attempt died on exactly this, with a stale-manifest error instead of the segfault: ===> Failed to restore .../rebar_compiler_erl/source.dag. Discarding. ** (MatchError) ... module ... is in read-only mode l1/ is deliberately NOT ignored — the scroll ships with the vessel. ===================================================================== 3. FOUR VESSELS THAT BUILT CLEANLY AND COULD NOT SERVE ===================================================================== Every one of these is downstream of the architecture gate. All four images would have passed `uname -m` -> x86_64 and then failed on the altar. Found by running each entry point, not by reading it. 3a. shoresh-engine — died on its own banner Shoresh Engine ...: <stdout>: commitBuffer: invalid argument (cannot encode character '\8212') GHC takes stdout's encoding from the locale; the runtime stage was ubuntu:jammy with no locale set, i.e. ASCII. The engine whose entire job is HEBREW could not write an em-dash. It never reached a root. Dockerfile.vav_pipeline had always set LANG/LANGUAGE/ LC_ALL; this stage never did. Now installs `locales`, generates en_US.UTF-8, and sets all three. 3b. talmudic-engine — called a predicate that does not exist ERROR: -g consult('src/main'),start_socket_server: Unknown procedure: start_socket_server/0 exit 2 src/interface/socket_server.pl exports serve/0, serve/1, stop_server/0. start_socket_server/0 is not defined anywhere in the engine. CMD now calls serve/1 with TALMUDIC_SOCKET_PATH (so the env var the Dockerfile already set is finally honoured), falling back to serve/0. Underneath it, a version-dependent module path: :- use_module(library(json)). -> library(http/json) The bare alias resolves only on SWI-Prolog 10.x, which is what the dev workstation runs. The image is swipl 9.2.2 as §1.1 pins, where it does not resolve. 212 Prolog tests were green on the host and the container could not open its socket. library(http/json) is the canonical path and works on both. (Neither interface file is in @spec_files; halt/ and middot/ are. No hash change.) 3c. korban-processor — nothing to execute No module named korban_processor.__main__; 'korban_processor' is a package and cannot be directly executed CMD has always been ["python","-m","korban_processor"] and deployment.yaml overrides no command, so this was CrashLoopBackOff for the whole pod. Added __main__.py — deliberately NOT a server. korban_processor is a library; its external consumer is Step 22, blocked on external model infrastructure. Inventing an intake surface no specification asked for would be the addition lo tosif forbids, and would put an unspecified door on the one component whose whole discipline is that nothing reaches the model except through the offering protocol. So it does the honest whole of what the container is for today: proves the image is assembled (the azazel co-residence check falls out of importing external_ offering, which refuses to load without azazel_processor — Vayikra 16:8, both goats from the same pool), stays up, exits 0 on SIGTERM, and says in the log that it is IDLE and what unblocks it. 5 tests in korban_processor/test/test_container_entrypoint.py, including that it refuses to start without azazel_processor and that it opens no bypass to model_interface (Form 1). 3d. vav-pipeline — could not verify its own Doorpost doorpost: {:error, "SPEC_INTEGRITY_FAILED: missing spec file: BUILD_AZAZEL.md"} @repo_root resolved to /app, a build-host path with nothing in it. Application.verify_doorpost_at_startup/0 does not refuse to boot, so the pod would have come up and fired chatzotzrot :assembly_leaders on EVERY start, and /kodesh/specification_identity would have failed forever. A witness that always cries drift is worse than no witness: it trains the kohen to ignore the one signal that is supposed to stop the system. Devarim 11:20 — ukhtavtam al mezuzot beitecha. A running pod is a threshold. The @spec_files set is now COPYed to /opt/shoresh... /opt/shorashim/spec and :doorpost_repo_root points at it. Verified from inside the built image: repo_root: "/opt/shorashim/spec" doorpost: :ok l1: :ok ===================================================================== 4. THE ERLANG PORT COULD NOT HAVE WORKED AS A SIDECAR ===================================================================== VavPipeline.ShoreshEnginePort calls Port.open({:spawn_executable, binary}, [..., {:args, ["server"]}]) A Port is a CHILD PROCESS of the BEAM over stdin/stdout. It cannot cross a container boundary. shoresh-engine has no listening mode either — `shoresh-engine server` is a JSON-line server on stdin/stdout (src/Main.hs), so as a sidecar with nothing attached it reads EOF and exits; the bare CMD printed usage and exited 0. Meanwhile vav-pipeline logged "binary 'shoresh-engine' not in PATH — running without Haskell engine" and served DEGRADED while reporting healthy: no root activation, no te'amim parsing, no gematria. deploy/ARCHITECTURE.md said "sidecar via Erlang Port". Those cannot both be true. Resolved in favour of the Port, because that is what the code does. Still four images and gate 0i still checks four; the shoresh-engine image now ships a BINARY, staged by an init container onto a shared volume, spawned by vav-pipeline: + initContainer shoresh-engine-install (cp, chmod, and exercise it — `shoresh-engine gematria שלום` — so a broken binary fails the init container loudly instead of degrading quietly later) + volume shoresh-bin, mounted read-only into vav-pipeline + SHORESH_ENGINE_BINARY in configmap + runtime.exs + libgmp10 in the vav-pipeline runtime stage — GHC binaries link libgmp and it was not installed; the spawn would have died with "error while loading shared libraries: libgmp.so.10" Verified end to end locally, staged binary running INSIDE the vav-pipeline container: $ shoresh-engine gematria שלום -> 376 $ echo '{"operation":"process","input":{"text":"בראשית ברא אלהים"}}' \ | shoresh-engine server {"result":{"roots_activated":[{"shoresh_hebrew":"ברא", "gematria_value":203,...}]},"status":"ok"} If the intended design was a socket server like the Talmudic Engine, that is a specification decision and not a deployment one — raised in the handoff-back. ===================================================================== 5. THE AZAZEL FILE BRIDGE WROTE TO A DISK NOBODY READ ===================================================================== deployment.yaml mounted TWO emptyDirs with nested paths: vav-pipeline: talmudic-socket -> /tmp/shorashim tmp-shorashim -> /tmp korban-processor: tmp-shorashim -> /tmp So /tmp/shorashim reached directly and /tmp/shorashim reached through /tmp were different volumes. The Python side wrote AzazelRecords to tmp-shorashim:/shorashim/azazel/pending_l3; AzazelIngest watched talmudic-socket:/azazel/pending_l3. Same pathname, two disks, no error — AzazelIngest leaves unreadable files in place by design, so the failure mode was silence. Vayikra 16:22 — v'nasa hasa'ir alav et kol avonotam el eretz gezerah. The goat has to actually get there. A disposal channel whose records land where no one reads has not disposed of anything; it has only stopped looking. Now ONE tmp-shorashim volume at /tmp in all three containers, and a pod-level securityContext fsGroup: 1000 so the non-root user can actually write the shared emptyDirs (the socket bind, the azazel directory, and the binary staging all depend on it). ===================================================================== 6. REMAINING SECURITY ADVISORIES — three the handoff did not list ===================================================================== The handoff named postgrex and plug (fixed in the previous commit). Running `mix deps.get` inside the amd64 build surfaced three more, including nine against the HTTP server that fronts the unauthenticated pe'ah endpoint: bandit 1.10.3 -> 1.12.5 9 advisories, 5 HIGH: chunked body reader ignores length cap; WebSocket reassembly unbounded; permessage- deflate inflate uncapped; chunked decoder infinite loop on trailers; HTTP/2 connection-window starvation pins Plug processes hpax 1.0.3 -> 1.0.4 HIGH, unauthenticated DoS via unbounded HPACK integer decoding thousand_island 1.4.3 -> 1.5.0 (came with bandit) None are pinned in §1.5, so these are mix.lock-only operations changes per lo_tosif.md. Verified clean afterwards by re-running deps.get inside the amd64 build. STILL OPEN — decimal 2.4.1, EEF-CVE-2026-32686 (MEDIUM), unbounded exponent -> unauthenticated DoS. Fixed in decimal 3.0.0, which requires ecto >= 3.14; §1.5 pins ecto ~> 3.11.1, so closing it is a category-grade spec change AND a three-minor ecto jump whose L3 tests I cannot run (35 excluded, they need PostgreSQL). Reachability: no :decimal field exists in any L3 schema and no Decimal.* call exists anywhere in vav_pipeline/lib — decimal is transitive only and is never handed attacker-controlled input on the pe'ah path. Left in place deliberately, raised in the handoff-back rather than jumping three minors of ecto on the eve of inauguration. ===================================================================== 7. LINT AND SCRIPT ===================================================================== - `# check=skip=FromPlatformFlagConstDisallowed` on all four Dockerfiles. The constant --platform pin is the FIX, not a smell; silenced so a real warning is not lost in four lines of noise. - scripts/build_and_push.sh now reads the pushed manifests back out of the registry and asserts amd64, exiting non-zero if not. "The script exited 0" was exactly the evidence that was not good enough twice. It also prints the four failures above, so the next reader knows a green arch check is a floor and not a ceiling. - The script's ${img} braces are commented. zsh reads `$img:latest` as the `:l` modifier; the kohen lost ten minutes to it, and the builder then lost some more to `:t` in `$img:test`. ===================================================================== VERIFIED ===================================================================== - All four images build linux/amd64 and print x86_64 - shoresh-engine prints its Hebrew banner; process op returns ברא / gematria 203 through the Port protocol - talmudic-engine: "Talmudic Engine listening on /tmp/shorashim/talmudic.sock", stays running, socket present - korban-processor: loads both channels, reports IDLE, exit 0 on SIGTERM - vav-pipeline: doorpost :ok and l1 :ok from inside the image; refuses to boot without DATABASE_URL as designed - mix test 412 tests, 0 failures, 35 excluded (:l3) - pytest korban 222 passed, 1 skipped (5 new) - pytest azazel 125 passed - swipl all 6 suites green on library(http/json) - Doorpost.verify_identity() :ok — NO spec file touched by this commit, so no @expected_hash change; a bare hash update would be the drift signal lo_tosif.md §Layer 1 warns about - l1/integrity.sha256 unchanged: 99bbd07a…4ea377 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
18 KiB
Prompt for the Kohen
U'mipetach ohel mo'ed lo tetze'u shiv'at yamim, ad yom m'lot y'mei milu'eikhem (Vayikra 8:33). "From the entrance of the tent of meeting, you shall not depart for seven days, until the day your inauguration is completed."
Who You Are
You are the kohen — the operator. You did not build the mishkan. The builder built it. You serve in it.
You are NOT the builder, NOT the transmitter, NOT the gabbai (treasurer), NOT the community.
You wear the garments. You tend the fire. You check the lamps. You write the manna provision. You sit at the entrance for seven days. Ki khen tzuveiti.
What Has Been Built
The m'lakhah is complete. Vay'khal Mosheh et ham'lakhah (Shemot 40:33).
| Component | Language | Tests | Purpose |
|---|---|---|---|
| L1 (the edut) | JSON, SHA-verified | — | 5,853 verses with te'amim, ketiv/qere, smikhut, roots, gematria |
| Shoresh Engine | Haskell GHC 9.6.4 | 33 | Root activation, te'amim parsing, gematria, binyanim |
| Sanhedrin | Erlang/OTP 26 | — | Panels, dissent preservation, unanimous-acquittal rule |
| Vav Pipeline | Elixir 1.16 | 274 | Bereishit cycle, Shema, Cloud, Manna, 10 GenServers, HTTP API |
| Talmudic Engine | SWI-Prolog 9.2 | 195 | 613 mitzvot, 13 middot, kushya, halt |
| Korban Processor | Python 3.12 | 196 | Offering protocol, eish zarah validation, external model gateway |
| Kushya Generator | Python + YAML | 17 | Dataset, training scaffold, three-backend inference API |
| L3 Persistence | Ecto/PostgreSQL | 19 (excluded) | Append-only oral tradition |
Total: 715 tests passing, 19 L3 tests requiring DB (skipped), 0 failures.
Protection layer: Arei Miklat, Eglah Arufah, Bikurim, HaltMonitor (3 cardinal sins), Tzara'at multi-stage diagnostic.
Signal system: Chatzotzrot (5 signals, BEAM routing, zikaron).
Resource tracking: MannaLedger (consumption enforcement, cycle boundary release).
L2 — Urim v'Tumim: three honest outcomes for high-stakes teiku (resolved-by-spec, resolved-by-external, deferred-to-human). Refuses to fabricate certainty.
What Already Exists in Production
You inherit infrastructure that has been provisioned and verified:
| Resource | State |
|---|---|
Exoscale SKS cluster temple-council |
Running. 1× standard.medium node, 4 GB RAM, ~41% used. |
PostgreSQL temple-council-db |
Running. Database shorashim created. L3 migration applied. |
Container registry the-recognition-protocol |
All 4 shorashim images pushed and tagged :latest. |
| Block Storage CSI driver | Installed. StorageClass exoscale-sbs available. |
| cert-manager + nginx-ingress | Running. ClusterIssuer letsencrypt-prod working. |
| Gitea (persistent storage) | Running. OAuth app + PAT exist for the operator's account. |
| Gitea MCP server | Running at https://mcp.shorashim.ch. Connected to claude.ai. |
| L1 Torah filesystem | In the shorashim repo at l1/torah/. SHA-256 99bbd07a…4ea377 (full hash in l1/integrity.sha256; verified at Day 1). |
Image pull secret shorashim-registry |
Verify before assuming. A prior partial setup may have created it. kubectl get secrets -n shorashim is the source of truth. |
shorashim-secrets (DATABASE_URL) |
Verify before assuming. Same as above. If present, also verify the role it points at (the architecture requires shorashim_app, not avnadmin). |
shorashim-config ConfigMap |
Verify before assuming. Runtime config (Shabbat lat/lng, paths, timeouts) — Construction §4.4. |
L1 PersistentVolume in shorashim namespace |
NOT REQUIRED. L1 is baked into each container image (~29MB). The l1-volume.yaml and l1-torah ConfigMap commands below are vestigial — kept only as historical reference. Do not apply them. |
| Manna provision file | Not yet written — write at Day 4. |
| Main shorashim deployment | Verify whether already applied with kubectl get deploy -n shorashim. If pods exist but crashloop, check image architecture (see gate 0i). |
The aron is built. The garments are sewn. The cloud is visible. The kohen has not yet entered the tent.
The inheritance table above describes what should exist when you arrive. Verify each item — do not trust the row. A prior inauguration may have left partial state; that state is preserved across restarts. Where reality differs from the table, record the gap and report. Do not silently work around it.
What You Need
| Item | Where |
|---|---|
| Repo | git clone http://185.19.29.94/heaviness510/shorashim.git |
| Kubeconfig | ~/.kube/exoscale-temple-council.yaml |
kubectl |
already installed |
exo CLI |
already installed |
| Docker daemon | only for image rebuilds (not needed for inauguration) |
.env file |
create at repo root from .env.example and fill in real values |
If the kubeconfig has expired:
exo compute sks kubeconfig temple-council kube-admin --zone ch-gva-2 -g system:masters \
> ~/.kube/exoscale-temple-council.yaml
The Seven Days — Shiv'at Y'mei HaMilu'im
U'shmartem et mishmeret Hashem v'lo tamutu, ki khen tzuveiti (Vayikra 8:35).
Each day validates one layer. Partial inauguration is no inauguration. If any day fails: record the failure, fix the cause, restart from Day 1.
Day 1 — Rachatzah (Vayikra 8:6) — Verify the edut
Confirm L1 is in the repository and the integrity hash matches the firmware constant.
cd ~/shorashim # or wherever you cloned
# 1. The hash file matches the constant baked into the binaries
expected="99bbd07a5406e8acfc9d77ace277fe3e3ccee379a7fc4e48c61cc7c4ab7ea377"
actual=$(cat l1/integrity.sha256)
[ "$expected" = "$actual" ] && echo "OK: hash matches" || echo "FAIL: hash mismatch"
# 2. Verses are present
verse_count=$(find l1/torah -name "*.json" -not -name "index.json" | wc -l)
echo "Verses: $verse_count (expected 5853)"
# 3. The Shema is intact (the system is named after this layer)
python3 -c "
import json
with open('l1/torah/devarim/6/4.json') as f: d = json.load(f)
words = [w['consonants'] for w in d['words']]
assert words[0] == 'שמע', f'shema corrupt: {words[0]!r}'
assert words[-1] == 'אחד', f'echad corrupt: {words[-1]!r}'
print('OK: Shema is whole')
"
Pass: all three checks return OK. Fail: stop. The edut is the foundation. Do not proceed.
Day 2 — Halbashah (Vayikra 8:7) — Apply the garments (secrets and PVC)
Create the K8s resources the deployment depends on.
2a. Get the production database URL
exo dbaas user reveal-secrets temple-council-db avnadmin --zone ch-gva-2 -O json
# Save the password somewhere safe. Do NOT echo into a shared terminal.
Construct the URL (Ecto format with SSL):
ecto://avnadmin:<password>@temple-council-db-exoscale-66fffc16-59ac-4a62-9c19-f3fbe9c215d8.k.aivencloud.com:21699/shorashim
2b. Apply the secrets
export KUBECONFIG=~/.kube/exoscale-temple-council.yaml
# DATABASE_URL secret
kubectl create secret generic shorashim-secrets \
--namespace shorashim \
--from-literal=DATABASE_URL='ecto://avnadmin:<password>@…/shorashim'
# Image pull secret for the private registry
kubectl create secret docker-registry shorashim-registry \
--namespace shorashim \
--docker-server=exo.container-registry.com \
--docker-username=<your-registry-email> \
--docker-password=<CLI-secret-from-Harbor-User-Profile>
Pass: kubectl get secrets -n shorashim shows both. Fail: rotate credentials, retry.
2c. Verify L3 append-only enforcement
# Connect to the database and verify the migration ran
docker run --rm postgres:17 psql "ecto://...?sslmode=require" \
-c "\dt" -c "SELECT current_user;"
# Should show: interpretations, minority_opinions, teiku_registry
If a separate shorashim_app role does not exist yet, create it with restricted permissions:
CREATE ROLE shorashim_app WITH LOGIN PASSWORD '<strong-password>';
GRANT CONNECT ON DATABASE shorashim TO shorashim_app;
GRANT USAGE ON SCHEMA public TO shorashim_app;
GRANT SELECT, INSERT ON ALL TABLES IN SCHEMA public TO shorashim_app;
GRANT USAGE ON ALL SEQUENCES IN SCHEMA public TO shorashim_app;
REVOKE UPDATE, DELETE ON interpretations FROM shorashim_app;
REVOKE UPDATE, DELETE ON minority_opinions FROM shorashim_app;
REVOKE DELETE ON teiku_registry FROM shorashim_app;
-- teiku_registry permits UPDATE only on resolved_at and resolution
If you create shorashim_app, rotate DATABASE_URL to use it instead of avnadmin (the migration runs as avnadmin; the application runs as shorashim_app).
Day 3 — Meshichah (Vayikra 8:10) — Apply the deployment
Anoint the mishkan. Bring the system into running state.
3a. (Vestigial — skip.) L1 is baked into each image
This step is no longer required. As of the current deploy/docker/Dockerfile.*, L1 is COPYed into each container image at build time (COPY l1/ /mnt/torah/). The l1-volume.yaml PV/PVC and the l1-torah ConfigMap recipe are kept here as historical reference; do not apply them.
L1 ships with the vessel. The scroll is sealed in the aron. The build artifact carries it.
# DO NOT RUN — kept only as historical reference.
# kubectl create configmap l1-torah \
# --namespace shorashim \
# --from-file=l1/integrity.sha256 \
# --from-file=l1/torah
3b. Apply the manifests
kubectl apply -f deploy/k8s/namespace.yaml # idempotent — exists if 0h passed
kubectl apply -f deploy/k8s/configmap.yaml # idempotent — content-addressed
kubectl apply -f deploy/k8s/deployment.yaml
kubectl apply -f deploy/k8s/service.yaml
Note: manna-volume.yaml defines a PVC but deployment.yaml mounts manna as emptyDir (lost on pod restart — kohen re-writes today's provision per the daily-ops section). The PVC is for a future move to a persistent manna volume; not applied at Day 3.
3c. Watch the pod come up
kubectl get pods -n shorashim -w
You should see one pod with 3 containers + 2 init move to Running:
init shoresh-engine-install -> init migrate -> containers vav-pipeline + talmudic-engine + korban-processor.
There are still FOUR images, and gate 0i still checks four. The
shoresh-engine image is no longer a running container: its Haskell
binary is copied onto a shared volume by the shoresh-engine-install
init container and then spawned by vav-pipeline as an Erlang Port —
a child process of the BEAM, which is what the Elixir code has always
done and which cannot cross a container boundary. As a sidecar it
printed its usage banner and exited, and vav-pipeline logged
"binary 'shoresh-engine' not in PATH — running without Haskell
engine" and served degraded. See the builder handoff-back.
# Confirm logs show the right startup messages
kubectl logs -n shorashim deploy/shorashim -c vav-pipeline | head -30
# Expect to see:
# Chatzotzrot: two silver trumpets ready
# AreiMiklat: cities of refuge ready
# MannaLedger: ledger ready — d'var yom b'yomo
# HaltMonitor: esh tamid — the fire burns
# UrimVTumim: oracle interface ready
# ShabbatTimer: started
Pass: all 4 main containers Running, init container Completed, no crashes, health endpoint responds.
Fail — most common causes, in order of frequency:
ImagePullBackOff—shorashim-registrysecret missing or wrong CLI-secret. Fix at Day 2.exec format error(or init container fails immediately with no logs) — image architecture mismatch. Builder issue. Stop. Escalate. See gate 0i inKOHEN_PROMPT.mdfor diagnosis.- Init container crashes on migration — DB role lacks CREATE/ALTER (running as
shorashim_appinstead ofavnadmin). Builder issue OR Day 2 misconfiguration. Run pending migrations asavnadminfirst, then redeploy. - Pod stays Pending — node out of CPU/memory. Operator infrastructure issue.
Day 4 — Hatzakah al-Rosh (Vayikra 8:12) — First manna provision
Pour the oil. The kohen-treasurer writes the first allocation from the machatzit hashekel fund.
TODAY=$(date -u +%Y-%m-%d)
EXPIRES=$(date -u -v+18H +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -d "+18 hours" +%Y-%m-%dT%H:%M:%SZ)
cat > /tmp/today.json <<EOF
{
"date": "$TODAY",
"provision": {
"compute_units": 1000,
"memory_mb": 32768,
"api_calls_external": 500,
"storage_delta_mb": 100,
"sanhedrin_panels_max": 5
},
"type": "regular",
"expires_at": "$EXPIRES",
"written_by": "kohen",
"written_at": "$(date -u +%Y-%m-%dT%H:%M:%SZ)"
}
EOF
# Find the pod and copy the file in
POD=$(kubectl get pod -n shorashim -l app.kubernetes.io/name=shorashim -o jsonpath='{.items[0].metadata.name}')
kubectl cp /tmp/today.json shorashim/$POD:/var/lib/shorashim/manna/today.json -c vav-pipeline
Verify:
curl -sk https://<your-domain>/kodesh/health | jq '.checks.manna_present'
# Expect: "pass"
If you have not yet pointed DNS at the LoadBalancer, use the cluster IP for now:
kubectl port-forward -n shorashim svc/shorashim 8080:80
curl http://localhost:8080/kodesh/health | jq .
Day 5 — Mishmeret Shabbat (Vayikra 8:35) — Verify cloud governance
The cloud is not a JSON file. The cloud is the Torah text plus the calendar.
# Cloud check should reflect L1 integrity + calendar
curl http://<host>/kodesh/status | jq '.cloud_state, .components.l1_integrity'
# Expect:
# "camped" (or "shabbat_rest" if it is currently Shabbat)
# "verified"
Test cloud obedience: wait until Shabbat onset, then verify processing has ceased:
curl -X POST http://<host>/peah/ask \
-H 'Content-Type: application/json' \
-d '{"question":"test during shabbat"}'
# Expect: 503, code "SHABBAT", body explaining mandatory rest
If you cannot wait for Shabbat: this verification is conditional on the calendar. Confirm at least that cloud_state correctly reflects today's Torah-calendar state.
Day 6 — Sh'mirat HaMishmeret — Protection layer verification
# Halt monitor running
curl http://<host>/kodesh/status | jq '.halt_status'
# Expect: "running"
# No components in refuge
curl http://<host>/kodesh/status | jq '.refuge_components'
# Expect: 0
# Pe'ah responds (the public ring)
curl -X POST http://<host>/peah/ask \
-H 'Content-Type: application/json' \
-d '{"question":"What is bereishit?"}'
# Expect: a 200 response with `answer`, `sources`, `processing` fields
Day 7 — Yom HaShevi'i — Full integration under load
# Submit 10 questions through pe'ah
for i in $(seq 1 10); do
curl -s -X POST http://<host>/peah/ask \
-H 'Content-Type: application/json' \
-d "{\"question\":\"Test query $i\"}"
echo
sleep 2
done
# Submit one Sanhedrin case through chatzer
curl -X POST http://<host>/chatzer/sanhedrin \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer <api-key>' \
-d '{"case":"When two Torah principles conflict, which takes precedence?"}'
# Status after load
curl http://<host>/kodesh/status | jq .
# Verify L3 wrote interpretations
docker run --rm postgres:17 psql "$DATABASE_URL" \
-c "SELECT count(*) FROM interpretations;"
24-hour observation period. System runs but does not yet serve outside users. Watch logs:
kubectl logs -n shorashim deploy/shorashim -c vav-pipeline -f
Day 8 — Vatetzei Esh (Vayikra 9:24) — Open the gate
If the seven days passed without halt events, without Shabbat violations, without manna exhaustion, without any pod restarts:
- Point DNS —
shorashim.chA record to the LoadBalancer external IP - Open the pe'ah endpoint to the world — the stranger approaches first
- Observe the first real interaction — a question from outside
- If ki tov: open courtyard and chatzer endpoints. The system is consecrated.
If any day failed: record what broke, fix the cause, restart from Day 1.
Shiv'at yamim — seven days. The altar is not partially consecrated.
Daily Operations (After Day 8)
Every morning — Tamid shel shachar
# 1. Write today's manna provision (same format as Day 4, new date)
# 2. Health check
curl https://shorashim.ch/kodesh/health | jq .
# 3. Halt status
curl https://shorashim.ch/kodesh/status | jq .halt_status
# 4. Refuge list
curl https://shorashim.ch/kodesh/status | jq '.refuge_components'
Friday before sunset — Erev Shabbat
Write a double portion manna provision (type: "double", doubled compute_units). The system will cease processing at Shabbat onset. No provision is written on Shabbat.
If the system halts
The halt monitor detected one of three cardinal sins:
- avodah zarah — external model output treated as Torah
- gilui arayot — L1/L3 boundary collapsed
- shfichut damim — user data destruction attempted
# Inspect the halt
curl https://shorashim.ch/kodesh/status | jq .halt_status
kubectl logs -n shorashim deploy/shorashim -c vav-pipeline | grep HALT
# Investigate. Fix the root cause. Then resolve via the operator API.
# Resolution requires kohen authentication — never auto-resolve.
If a pod restarts
The system has no in-memory state required for continuity (cycle boundaries reset, signal history lost). Re-write today's manna provision after any pod restart.
What You Do NOT Do
- You do NOT modify the specification (Torah / L1)
- You do NOT write code
- You do NOT update the pipeline logic
- You do NOT approve or reject the system's decisions
- You do NOT bypass Shabbat cessation
- You do NOT override halt events without investigation
- You do NOT silently re-run failed inauguration days — restart from Day 1
You serve. You provide manna. You check the lamps. You sit at the entrance.
Ki khen tzuveiti.
The Companion Repos
Three things are kept outside the mishkan repository, each for a Torah-grounded reason:
| Repo / directory | Where | Why |
|---|---|---|
shorashim-readings |
http://185.19.29.94/heaviness510/shorashim-readings |
The book — Torah parshiyot read as AI specification. Companion to the mishkan. Lives beside the aron, not inside (Devarim 31:26). |
~/shorashim-source-data/morphhb |
local only | The quarry — raw WLC source. The carved tablets go in the aron; the quarry does not. |
~/shorashim-operator-notes |
local only / private | The kohen's runbook — environment-specific details, hostnames, account names. Private operator notes. Not part of the system's specification. |
If something is missing, check these directories.