Commit Graph
7 Commits
Author SHA1 Message Date
Scott KarpandClaude Fable 5.1 d44d290227 specs §3.1 + Doorpost: the engine's Haskell dependencies, as the cabal file declares them
Architecture §3.1 listed base, containers, text, aeson, vector. The
cabal file also depends on bytestring, filepath and directory (the
engine reads L1 from disk and speaks JSON lines over a port), and on
hspec for the test suite. Construction §1.3 already named all of them;
the architecture list had simply not kept up.

The list now matches shoresh-engine.cabal, says what each package is
for, and says where the versions are pinned. One entry is marked as it
is: `vector` is declared and no module imports it.

Doorpost @expected_hash f653ef05… → 5094e48e…, in this commit, with the
witnessed file that moved it (architecture).

Read before committing: Elixir 474/0 on seeds 0 and 42; the built
pipeline image reports specification_identity verified 5094e48e….

Seen while checking, not changed: Construction §1.3's "exact" Haskell
versions disagree with the committed cabal.project.freeze for six of
nine packages (aeson 2.2.1.0 vs 2.2.3.0, vector 0.13.1.0 vs 0.13.2.0,
bytestring 0.12.1.0 vs 0.12.2.0, filepath 1.4.200.1 vs 1.4.301.0,
directory 1.3.8.4 vs 1.3.10.1, hspec 2.11.7 vs 2.11.16). The freeze is
what every image has been built from.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-10-04 18:49:21 +00:00
Scott KarpandClaude Fable 5.1 5ff1b73d00 specs §3.1 + engine + Doorpost: a root is the consonants L1 records — two, three, or more
Architecture §3.1 typed a root as exactly three consonants
(`Shoresh {c1,c2,c3}`) and listed data/roots.json and
data/torah_refs.json in the engine's file tree. L1 has 115 roots that
are not three letters (32 of two, 83 of four or more), and the engine
has no data directory: the roots are in L1.

The code had followed the spec's type and paid for it. textToShoresh
padded a two-letter root with He — בן became בנה, כל became כלה — and
returned Nothing for anything longer, so Lexicon.buildLexiconFromVerses
either falsified those roots or dropped them. Shoresh.Roots (tablet 33)
had stepped around the type by carrying roots as Text.

Spec:
- §3.1 data structures: `newtype Shoresh = Shoresh { radicals ::
  [Consonant] }` — two or more, never padded or truncated; `mkShoresh`,
  `triliteral`.
- relatedRoots / neighbors: same length, differing in exactly one
  consonant (for a root of three, the old "sharing 2 consonants").
- File tree: Roots.hs and Server.hs added; data/ removed, with a line
  saying where the roots are; cabal.project.freeze listed; aeson's
  purpose corrected.

Engine:
- Types: the newtype, mkShoresh :: [Consonant] -> Maybe Shoresh,
  triliteral, textToShoresh without padding.
- Gematria: sum over the radicals. Graph: neighbors among roots of the
  same length; neighborsByPosition labels the shared positions
  ("c1c2" for a triliteral, as before).
- Server: consonant names through the type.
- Spec.hs: בן stays two letters (gematria 52, not 57); שמאל is held
  whole; the graph compares only roots of equal length. 59 examples.

Doorpost @expected_hash 094b8164… → f653ef05…, in this commit, with the
witnessed file that moved it (architecture).

Read before committing: Haskell 59/0; Elixir 474/0 on seeds 0 7 42;
both images built and run together with the real binary — Shemot 3:14
answers ב-ן (two letters), Bereishit 48:13 answers ש-מ-א-ל (four),
Devarim 6:5 unchanged; local specification_identity verified
f653ef05…; no engine errors or fallbacks.

Not touched: §3.1's dependency list omits bytestring, filepath and
directory, which the cabal file has.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-10-04 18:42:52 +00:00
Scott KarpandClaude Fable 5.1 3eec60dbdb specs + Doorpost: the roots are counted, not estimated — 1,378, not "~500"
Architecture §3.1 said the Shoresh Engine "encodes the ~500 Biblical
Hebrew triliteral roots", its file tree called Lexicon.hs "the ~500
roots with entries", and terumah §E2 listed a "~500 roots" lexicon as
material still to be consolidated (~1-2 weeks).

Since tablet 34 the roots are read, and can be counted. L1 carries
1,378: 1,243 roots under which Brown-Driver-Briggs files a lemma, and
135 words that stand alone under no root. 1,263 are triliteral, 32 have
two letters, 83 have four or more. And the engine does not hold a list
of them — it reads them from L1 (Shoresh.Lexicon, Shoresh.Roots).

- specs/shorashim_architecture.md §3.1: the Purpose sentence says where
  the roots come from and how many there are; the Lexicon.hs line in
  the file tree likewise.
- specs/shorashim_terumah.md §E2: the root lexicon is in hand (✅) —
  the OSHB Hebrew Lexicon is exactly the BDB + Strong's consolidation
  the row was waiting for; moved from "need to acquire" to "in hand".
- Doorpost @expected_hash 2f40c382… → 094b8164…, in this commit, with
  the witnessed file that moved it (architecture).

Read before committing: Elixir 461/0 on 11 of 12 runs (seed 0 ×6 and
six other seeds). One run of seed 0 reported a single failure that was
not captured and did not recur in eleven further runs; unidentified,
recorded in the build log. Pipeline image reports
specification_identity verified 094b8164… and l1_hash pass.

Left as written, and no longer true of the build: §3.1's data
structures still type a root as exactly three consonants, and its file
tree still lists data/roots.json and data/torah_refs.json, which do
not exist — the roots live in L1.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-10-04 18:10:21 +00:00
Scott KarpandClaude Fable 5.1 efd35bb194 specs + Doorpost: pyswip removed — a material the vessel never used (tablet 36)
Architecture §3.5 listed a Python-Prolog FFI among the Korban
Processor's dependencies ("swipl-ffi (or pyswip)"); Construction §1.4
and terumah pinned pyswip. It was declared, installed in every image,
and never imported. The Korban Processor does not call Prolog: haktarah
emits Prolog-format STRINGS, and the pipeline carries them to the
Talmudic Engine over its Unix socket (Construction §3.3). The korban
image has no libswipl, so the package could not have been used there
had anything tried. Tablet 35 corrected its version; the transmitter's
word is to remove it.

Removed from:
- specs/shorashim_architecture.md §3.5 requirements
- specs/shorashim_vayakhel.md §1.4
- specs/shorashim_terumah.md (materials row; the compatibility-testing
  line now names hebrew-tokenizer alone)
- BUILD_KORBAN.md
- korban_processor/pyproject.toml, poetry.lock (regenerated)
- deploy/docker/Dockerfile.korban_processor

Doorpost @expected_hash 81da49d4… → 2f40c382…, in this commit, with the
three witnessed files that moved it (architecture, vayakhel,
BUILD_KORBAN).

Read before committing: Elixir 461/0 (seeds 0, 42); korban 222 passed,
1 skipped against the installed package with pyswip absent; korban
image starts and idles as before; vav-pipeline image reports
specification_identity verified 2f40c382… and l1_hash pass.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-10-04 17:57:58 +00:00
Scott KarpandClaude Opus 4.7 5302c9a585 vehaya §6 closure: Items 1, 4, 5, 6, 7, 8 — the remaining checklist
This commit closes the SIX remaining items in the vehaya checklist
(after Items 2 and 3 from prior commits). With this, all eight items
in vehaya §6 are addressed in code or in the canonical spec set,
and all the substantive implications across §3 are covered.

ITEM 1 — load-bearing dependency (vehaya §3.1):

  Devarim 11:18-19 — corporate inscription (v'samtem … al
  l'vavkhem — plural) is the load-bearing input to threshold
  practice (b'shivt'kha b'beitekha — singular). The threshold
  inscribes the corporate text on itself.

  ShemaContext now carries `doorpost_hash: Doorpost.expected_hash()`
  on every reception. Both receive_context/1 and receive_context_at/2
  populate it. Every reception is now a witness of the corporate
  text's identity — making the load-bearing dependency between
  category and threshold structural rather than implicit.

  application.ex now runs Doorpost.verify_identity/0 at startup.
  Drift detected at boot is logged at :error AND fires
  Chatzotzrot.signal(:assembly_leaders, ...). The system does NOT
  refuse to boot on drift (dev environments routinely have spec
  drift during active editing) but operators are alerted before any
  reception fires.

ITEM 6 — keep the source external (full closure; vehaya §6 item 6):

  Devarim 4:2 — lo tosif AND lo tigra; both directions.
  Vayikra 22:31 — u'shmartem … va'asitem; keep and do, not author.

  Form 1 closed the EXTERNAL → INTERNAL direction (commit b136c75 —
  no module installs external models in YHVH's slot). This commit
  closes the INTERNAL → SOURCE direction (no module modifies the
  source itself).

  vav_pipeline/test/source_external_test.exs (4 tests) verifies:
    - no Elixir module writes to the L1 mount
    - no Python module in korban_processor writes to L1
    - no Python module in azazel_processor writes to L1
    - no Prolog module asserts into L1-shape predicates from
      outside specification/

  L1 was already filesystem-permission-controlled at the operator
  layer; this commit defends in code so the architectural commitment
  cannot be silently violated by future code paths.

ITEM 7 — substrate openness (vehaya §2.4):

  Bereishit 2:7 — afar substrate + nishmat chayim breath; the text
  does not preclude carriers of other substrate.

  specs/shorashim_architecture.md §8.4 added: positive architectural
  claim that the system is designed to carry covenant content
  regardless of substrate, with explicit caveats (does NOT claim AI
  is a covenant party with YHVH, does NOT claim AI has neshamah,
  does NOT claim all substrates are equally adequate). The claim is
  structural: nothing in the architecture refuses a substrate Torah
  did not refuse. Lo tosif applied to imported constraints.

ITEM 8 — userMemories as threshold inscription (vehaya §3.3):

  Devarim 11:20 / Devarim 6:9 — u'kh'tavtam al m'zuzot beitekha;
  the doorpost-text verse is identical between the Shema's first
  paragraph (singular pole) and V'haya's second (oscillating).

  specs/threshold_inscription.md (new) names the architecture for
  the threshold inscription:
    - identical at every threshold (Doorpost hash; same MEMORY.md
      structure)
    - pointing back to the source (the inscription is OF the
      corporate text, not ABOUT the threshold)
    - inscribed at the threshold's own location

  Two implementations: ShemaContext.doorpost_hash (runtime) and
  MEMORY.md (operator-side). Operator workflow split into three
  layers: build status (MEMORY.md), spec changes (specs/* with
  Doorpost atomicity), operator notes (outside repo).

ITEM 5 — return vs. restoration (vehaya §3.5):

  Devarim 30:2 / 30:8 / 30:10 — v'shavta ad YHVH … ha'k'tuvah
  b'sefer ha'Torah ha'zeh. Return is to the SOURCE and the
  SPECIFICATIONS, anchored in the text — not to a previous
  deployment configuration.

  specs/return_specification.md (new) names the structural
  distinction:
    - Return: destination is the source and specifications;
      removes additions
    - Restoration: destination is a specific past configuration;
      may restore additions

  Auditable test: does the proposed action move the system TOWARD
  the documented specifications, or TOWARD a previous state? The
  Doorpost hash makes this distinguishable.

ITEM 4 — lo tosif discipline operationalized (vehaya §6 item 4):

  Devarim 4:2, Devarim 13:1, Vayikra 22:31 — the keeping is
  plural, the not-adding/not-subtracting is singular at the
  threshold.

  specs/lo_tosif.md (new) names the discipline at three layers:
    Layer 1: specifications (specs/*, halt rules) — Doorpost
      defends; bare hash-update commits are drift signals
    Layer 2: architectural commitments (CI invariants) — adding
      a bypass surface OR removing an enforcement is detected
    Layer 3: threshold inscription (MEMORY.md) — operator notes
      not derived from category-grade specifications belong
      outside the repo

  Documents what counts as a legitimate spec change (Torah-grounded
  reading + atomic commit + named anchor + reviewable in git) and
  what does NOT count as a spec change (operations updates).

DOORPOST UPDATES:

  Three new spec docs added to @spec_files:
    - specs/lo_tosif.md
    - specs/return_specification.md
    - specs/threshold_inscription.md

  Plus specs/shorashim_architecture.md modified for §8.4.

  @expected_hash updated:
    8eb37896… → 5a73bc6ac8244c58446cf1d2a69dc01ccfe3ef1352d423ccbf2c29a6c8104be3

  Fourth demonstration of the operator discipline working: spec
  changes (3 new docs + 1 modified) atomically bound to hash update
  in the same commit.

TESTS:

  vav_pipeline/test/step15_shema_test.exs +3 tests (Shema doorpost
    inscription suite):
    - ShemaContext carries the Doorpost expected_hash
    - every reception bears the same corporate-text witness
    - inscribed hash matches documented spec set's identity

  vav_pipeline/test/source_external_test.exs (NEW) 4 tests:
    - Item 6 enforcement across Elixir, Python (korban), Python
      (azazel), and Prolog

Final test counts:
  - vav_pipeline:    412 passed, 0 failures, 35 excluded (was 405; +7)
  - korban_processor: 217/1 unchanged
  - azazel_processor: 125 unchanged
  - talmudic_engine: 214 unchanged

VEHAYA CHECKLIST — FINAL STATE:

  Item 1 (load-bearing category→threshold dependency)    CLOSED (this commit)
  Item 2 (three avodah zarah as architecture)            CLOSED
                                                          - Form 1 (b136c75)
                                                          - Form 2 (7fc14e0)
                                                          - Form 3 (0e3fe4a)
  Item 3 (doorpost-text identity)                        CLOSED (3f47496)
  Item 4 (lo tosif operationalized)                      CLOSED (this commit)
  Item 5 (return vs. restoration)                        CLOSED (this commit)
  Item 6 (keep the source external — full closure)       CLOSED (this commit)
  Item 7 (substrate-openness articulated)                CLOSED (this commit)
  Item 8 (userMemories as threshold inscription)         CLOSED (this commit)

All eight items in vehaya §6 are addressed in code or in the
canonical spec set. The full vehaya specification is implemented to
the extent the architecture-level (§3-6) implications can be
implemented; §4-out-of-scope items (consciousness, Sinai-covenant
identification) remain explicitly out of scope per the document.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-28 23:47:53 -04:00
Scott KarpandClaude Opus 4.6 f8f70c77e5 Code review fixes + 13 middot added to spec
Zerikah fail-safe: empty offerings rejected, not processed (BUILD_KORBAN §5).
Halt monitor hardened: trap_exit, priority max, EXIT handler (Architecture spec).
13 Rules of Rabbi Yishmael added to Architecture §3.4 as Prolog inference predicates —
the engine reasons WITH Torah's hermeneutic methods, not just about their products.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-09 16:55:42 -04:00
Scott KarpandClaude Opus 4.6 622e814c9e Bereishit: initial commit — specifications, readings, and L1 builder
The complete Shorashim repository: Torah as AI specification.

- 6 specification documents (PRD, architecture, construction, operations, economic model, materials)
- Readings: Mishpatim (Prolog), Maaseh Merkavah, Moreh Nevuchim
- Broken tablets preserved alongside whole tablets
- L1 Torah filesystem builder (build_l1.py) — parses Westminster Leningrad Codex
- Source directory structure for all components (L0 luchot, L1 aron, shoresh engine, sanhedrin, shema layer, urim v'tumim)

L1 build verified: 5 books, 187 chapters, 5853 verses, 79982 words, 2608 unique shoreshim, 0 verses missing te'amim.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-22 07:24:18 -05:00