heaviness510/bikoret
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
125 Commits 16 Branches 0 Tags
c0d0555aed61f22a74d86df1ebcc65a0045924f7
Commit Graph
6 Commits
Author SHA1 Message Date
Scott KarpandClaude Fable 5.1 c0d0555aed the name: Bikoret — code, contracts, images 
Headers X-Bikoret-Key / -Rebuke / -Verdict / -Bedikah; the `bikoret`
object and the "— bikoret …" fringe on a gate reply; environment
variables BIKORET_*; the image user and paths (/home/bikoret,
/tmp/bikoret, /var/lib/bikoret/manna, /etc/bikoret/secrets,
/opt/bikoret/spec); the tmp-bikoret pod volume; local databases
bikoret_dev/_test. Kubernetes resource names, the shorashim_app role and
the domain are unchanged (Tamid §1.1, "the names that still carry the
old word"). Doorpost c963c4fe…. Elixir 604/0, L3 10/0, korban 295,
Prolog bedikah 44/44. Gitea repo renamed heaviness510/bikoret (old URL
redirects).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
 2026-10-13 22:13:36 +00:00
Scott KarpandClaude Fable 5.1 5e325d36cc the second scroll: the mesorah snapshot, pinned and read (bishe'arecha step 6) 
Devarim 17:18 — the king writes his copy from before the priests, not from
memory. scripts/build_mesorah.py takes one open-licence version per work
per language from the Sefaria export (bucket sefaria-export, catalogue of
2026-10-02; Public Domain / CC0 / CC-BY / CC-BY-SA only, checked in every
file; no CC-BY-NC — the Bavli is Wikisource's) and lays it down beside
L1: mesorah/works/<slug>/{he,en}.json, index.json, integrity.sha256,
build_report.json. 128 works (Rashi, Onkelos, Ramban, Ibn Ezra, Sforno
on the Torah; all of Mishnah; 37 Bavli tractates; Bereshit and Shemot
Rabbah, Sifrei, Tanchuma), 256 files, 44.9 MiB, tree hash 7d5b3a6c…
computed as L1's (sorted relative path, then bytes; the two post-hash
files excluded). What is out, and why (licence), is in Terumah §E5.

Read, never fetched: korban_processor/mesorah.py finds citations as
written (Rashi on Devarim 6:5, Berakhot 2a, Mishnah Berakhot 1:1,
Bereshit Rabbah 1:1, Sifrei Devarim 32, Tanchuma Bereshit 1 …), resolves
each against the snapshot (complex works through their unnamed node,
Tanchuma by parashah), lists them as examination.mesorah_references, and
makes every passage found a given source for that examination — so a
claim about Rashi anchors in Rashi or does not. The Vav Pipeline couples
coupled(reference(R), mesorah(Work, [Address])) or not_in_mesorah; the
engine accepts mesorah/2 as a terminal and not_in_mesorah is Form 4.
VavPipeline.Mesorah pins the hash, re-reads the tree at startup and every
ten minutes, and /kodesh/health carries mesorah_hash. Mounted read-only at
/mnt/mesorah in the vav-pipeline and korban-processor images. L3
bedikot.mesorah (migration 20261013000002).

Also: the 1-in-12 Day6 serving failure of 2026-10-04 reproduced with seed
446116 — HaltMonitorTest left the system halted; it now resolves on exit
and the Day6 setup is defensive. Construction §3.11, Terumah §E5, Tamid
§1.1, bishearecha §IV, KOHEN, AGENTS. Doorpost 0638d4eb…. Elixir 604/0
(seeds 835592 and 446116), korban 294/1 skipped, Prolog bedikah 44/44,
L3 10/0.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
 2026-10-13 19:13:36 +00:00
Scott KarpandClaude Opus 5 8c221c2bcb build: four amd64 images that RUN — JIT segfault, build context, and four dead vessels 
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>
 2026-08-23 12:30:36 -04:00
Scott KarpandClaude Opus 4.6 5e6d16b0fa runtime.exs: Move DATABASE_URL to runtime config for OTP release 
OTP releases evaluate config at build time, not boot time.
DATABASE_URL must be read at runtime — the kohen sets it in
K8s secrets, not at compile time.

- Created config/runtime.exs with prod-only runtime config
- DATABASE_URL, L1_MOUNT_POINT, MANNA_PROVISION_FILE, HTTP_PORT
  all readable from environment at boot
- prod.exs cleaned: removed System.get_env("DATABASE_URL") call
  (was compile-time, now in runtime.exs)
- Added http_port: 4000 to prod defaults

Without this fix, the Docker image would fail to start — the
release would not find DATABASE_URL at boot.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-03-29 12:52:07 -04:00
Scott KarpandClaude Opus 4.6 d34e2799ac L3 Oral Tradition: PostgreSQL persistence layer for interpretations, minority opinions, teiku 
Devarim 17:9 — v'darashta v'higidu lekha et d'var hamishpat.
The inquiry requires that what is found is RECORDED.

- Ecto Repo with graceful degradation (maybe_add_repo, like other engines)
- Migration: interpretations, minority_opinions, teiku_registry tables
  - Append-only enforcement via REVOKE UPDATE/DELETE
  - Includes eish_zarah fields: coupling_trace, grounding_type, challenge_sequence
- Ecto schemas: Interpretation, MinorityOpinion, TeikuRecord
  - Changeset validations: status inclusion, panel_size > 0, grounding_type enum
  - TeikuRecord.resolve_changeset restricts updates to resolved_at/resolution only
- L3.Store bridge module: record, query, count operations
- L3 tests tagged @moduletag :l3, excluded by default (no local PostgreSQL)
  - Enable with: SHORASHIM_L3=1 mix test --include l3
- All 76 existing Elixir tests pass, 195 Prolog tests pass, 33 Haskell tests pass

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-03-17 09:43:44 -04:00
Scott KarpandClaude Sonnet 4.6 80ec364da6 Phase 1-2 build: Steps 5-6, 8-13 
Shoresh Engine (Haskell, Step 5)
- 12 modules: Types, Lexicon, Binyanim, Teamim, Gematria, Graph,
  KetivQere, Smikhut, Havdalah, Kriah, KiTov, Firmware
- 33 EUnit tests, 0 failures
- Firmware module verifies L1 SHA-256 hash at startup

Talmudic Engine (SWI-Prolog, Step 6)
- 15 modules: halt, reasoning, specification, interface
- 57 PlUnit tests, 0 failures
- Three cardinal halt conditions: avodah_zarah, shfichut_damim, gilui_arayot

Vav Pipeline (Elixir, Steps 8-11)
- 14 modules: BereishitCycle, Shema, Cloud, Manna, L1Reader,
  Specification, HaltConditions, ShabbatTimer, CycleLog, Chatzotzrot,
  ShoreshEngineClient, TalmudicEngineClient, Application
- 46 ExUnit tests, 0 failures
- Nishma-first architecture: hears before it speaks

Sanhedrin Framework (Erlang/OTP, Step 12)
- 8 modules: sanhedrin_app, sanhedrin_sup, escalation, panel_sup,
  panel, judge, clerk, halt_monitor
- 46 EUnit tests, 0 failures (includes fix: rejected outcome now reachable)
- Panel sizes: 1/3/23/71 — unanimous capital guilty → acquit (Sanhedrin 17a)
- Minority opinions append-only, never deleted

Korban Processor (Python, Step 13)
- 6 modules: korban, shechitah, semichah, zerikah, haktarah, router

Builder tooling: AGENTS.md, opencode.json, memory/, src/tools/

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-02-26 14:02:34 -05:00