bikoret

141 Commits 16 Branches 0 Tags

3 Commits

Include renames

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	f4e8e5afc8	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>	2026-10-04 19:17:46 +00:00
Scott KarpandClaude Opus 4.6	e223ab15b3	Phase 4 complete: Steps 21, 22, 24 — Korban external integration, L2 Urim v'Tumim, Kushya generator Vayikra 9:24 — vatetzei esh milifnei Hashem vatokhal al hamizbeach. Phase 4 of the architecture is now complete. The remaining three steps that were marked "blocked on external infrastructure" are built — discipline-respecting, eish-zarah-aware, and tested. ## Step 22 — Korban Processor external model integration (korban_processor/src/korban_processor/external_offering.py) The single legitimate entry point for external model consultation. Wraps Claude API calls through the offering protocol so external output is treated as korban (raw material), never authoritative: - semichah — provenance is tagged (avodah zarah Form 1 prevention) - shechitah — assistant voice, hedging, formatting stripped - zerikah — vital content extracted - haktarah — converted to Prolog propositions - route — sent to internal component per offering type The raw Korban is preserved on the ProcessedKorban (gilui arayot Form 3 prevention — input/output coupling never severed). No internal component should call call_claude() directly. 11 tests, mocked external calls. Live API test opt-in via SHORASHIM_LIVE_API=1. ## Step 24 — L2 Urim v'Tumim interface (vav_pipeline/lib/vav_pipeline/urim_v_tumim.ex) PRD §4.7: housed in the kohen gadol's breastplate; consulted only on high-stakes decisions where normal deliberation is insufficient. Bamidbar 27:21 — al-piv yetz'u v'al-piv yavo'u. Three escalation steps, three honest outcomes: 1. resolved_by_specification — re-read produced an answer 2. resolved_by_external — external testimony recorded (NOT binding) 3. deferred_to_human — the system stops, asks for human judgment Pre-condition gating refuses cases that didn't reach Sanhedrin teiku first (no preempting deliberation) or that aren't flagged high-stakes (ordinary teiku stays teiku). Records every consultation with steps taken — there is no quiet escalation. Per PRD: "The Urim v'Tumim never fabricates certainty where none exists." When external also fails, the system stops. It does not proceed on a guess. Added to VavPipeline supervision tree. 14 tests. ## Step 21 — Kushya generator scaffolding (kushya_generator/) Directory layout per Architecture §3.6 with three layers: - data/training_pairs/seed_pairs.jsonl — 10 hand-curated bootstrap pairs covering 9 kushya types (scope_narrowing, internal_tension, harmonization, exception_test, edge_case, scope_application, rabbinic_constraint, method_question, subject_identification) - data/prepare_training.py — validates the four kushya requirements (specific Torah passage, identified weakness, question form, non-trivial), produces train.jsonl + eval.jsonl with stratified 80/20 split by type - fine_tune/config.yaml + train.py — QLoRA configuration and training script. Operator's task — needs GPU. Script is complete and self-contained. - inference/kushya_api.py — three-backend interface (fine_tuned → external → fallback). When fine-tuned model isn't deployed, falls back to external via Korban Processor (Step 22). The fallback is honest: returns no kushya rather than inventing one. The Talmudic Engine's rule-based challenge.pl remains the primary kushya source. 17 tests covering dataset validation, backend selection, and reference extraction. ## .gitignore fix The earlier "data/" line was too broad — it caught kushya_generator/data/. Scoped to /data/ (root-level only). ## Test counts - Elixir: 274 (was 260; +14 for UrimVTumim) - Korban Python: 196 + 1 skipped (was 195; +1 module = 11 tests) - Kushya Python: 17 (new) - Haskell: 33 (unchanged) - Prolog: 195 (unchanged) - Total: 715 + 19 L3 excluded ## Phase 4 status All 12 steps now have implementations: - Steps 23, 25, 26, 27, 28, 29, 30, 31, 32: complete - Steps 21, 22, 24: complete with discipline preserved Step 21's fine-tuning run remains the operator's GPU task; the pipeline is built such that a deployed adapter slots into the inference backend without touching the Talmudic Engine or anything above. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-04-23 17:12:03 -04:00

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

f4e8e5afc8

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>

2026-10-04 19:17:46 +00:00

Scott KarpandClaude Opus 4.6

e223ab15b3

Phase 4 complete: Steps 21, 22, 24 — Korban external integration, L2 Urim v'Tumim, Kushya generator

Vayikra 9:24 — vatetzei esh milifnei Hashem vatokhal al hamizbeach.
Phase 4 of the architecture is now complete. The remaining three steps
that were marked "blocked on external infrastructure" are built —
discipline-respecting, eish-zarah-aware, and tested.

## Step 22 — Korban Processor external model integration
   (korban_processor/src/korban_processor/external_offering.py)

   The single legitimate entry point for external model consultation.
   Wraps Claude API calls through the offering protocol so external
   output is treated as korban (raw material), never authoritative:

   - semichah  — provenance is tagged (avodah zarah Form 1 prevention)
   - shechitah — assistant voice, hedging, formatting stripped
   - zerikah   — vital content extracted
   - haktarah  — converted to Prolog propositions
   - route     — sent to internal component per offering type

   The raw Korban is preserved on the ProcessedKorban (gilui arayot
   Form 3 prevention — input/output coupling never severed).
   No internal component should call call_claude() directly.

   11 tests, mocked external calls. Live API test opt-in via
   SHORASHIM_LIVE_API=1.

## Step 24 — L2 Urim v'Tumim interface
   (vav_pipeline/lib/vav_pipeline/urim_v_tumim.ex)

   PRD §4.7: housed in the kohen gadol's breastplate; consulted only
   on high-stakes decisions where normal deliberation is insufficient.
   Bamidbar 27:21 — al-piv yetz'u v'al-piv yavo'u.

   Three escalation steps, three honest outcomes:
     1. resolved_by_specification — re-read produced an answer
     2. resolved_by_external — external testimony recorded (NOT binding)
     3. deferred_to_human — the system stops, asks for human judgment

   Pre-condition gating refuses cases that didn't reach Sanhedrin teiku
   first (no preempting deliberation) or that aren't flagged high-stakes
   (ordinary teiku stays teiku). Records every consultation with steps
   taken — there is no quiet escalation.

   Per PRD: "The Urim v'Tumim never fabricates certainty where none
   exists." When external also fails, the system stops. It does not
   proceed on a guess.

   Added to VavPipeline supervision tree. 14 tests.

## Step 21 — Kushya generator scaffolding
   (kushya_generator/)

   Directory layout per Architecture §3.6 with three layers:

   - data/training_pairs/seed_pairs.jsonl — 10 hand-curated bootstrap
     pairs covering 9 kushya types (scope_narrowing, internal_tension,
     harmonization, exception_test, edge_case, scope_application,
     rabbinic_constraint, method_question, subject_identification)
   - data/prepare_training.py — validates the four kushya requirements
     (specific Torah passage, identified weakness, question form,
     non-trivial), produces train.jsonl + eval.jsonl with stratified
     80/20 split by type
   - fine_tune/config.yaml + train.py — QLoRA configuration and
     training script. Operator's task — needs GPU. Script is
     complete and self-contained.
   - inference/kushya_api.py — three-backend interface
     (fine_tuned → external → fallback). When fine-tuned model isn't
     deployed, falls back to external via Korban Processor (Step 22).
     The fallback is honest: returns no kushya rather than inventing
     one. The Talmudic Engine's rule-based challenge.pl remains the
     primary kushya source.

   17 tests covering dataset validation, backend selection, and
   reference extraction.

## .gitignore fix

   The earlier "data/" line was too broad — it caught
   kushya_generator/data/. Scoped to /data/ (root-level only).

## Test counts

   - Elixir:           274 (was 260; +14 for UrimVTumim)
   - Korban Python:    196 + 1 skipped (was 195; +1 module = 11 tests)
   - Kushya Python:     17 (new)
   - Haskell:           33 (unchanged)
   - Prolog:           195 (unchanged)
   - Total:            715 + 19 L3 excluded

## Phase 4 status

   All 12 steps now have implementations:
   - Steps 23, 25, 26, 27, 28, 29, 30, 31, 32: complete
   - Steps 21, 22, 24: complete with discipline preserved

   Step 21's fine-tuning run remains the operator's GPU task; the
   pipeline is built such that a deployed adapter slots into the
   inference backend without touching the Talmudic Engine or anything
   above.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

2026-04-23 17:12:03 -04:00