0572a2cffd298b22dca4c9256b129901f37f2a54
11
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Scott KarpandClaude Opus 5
|
0572a2cffd |
specs §1.5 + Doorpost: postgrex ~> 0.22.3 — ma'akeh before the roof is walked on
TORAH ANCHOR — Devarim 22:8:
כִּי תִבְנֶה בַּיִת חָדָשׁ וְעָשִׂיתָ מַעֲקֶה לְגַגֶּךָ וְלֹא תָשִׂים
דָּמִים בְּבֵיתֶךָ כִּי יִפֹּל הַנֹּפֵל מִמֶּנּוּ.
"When you BUILD a new house, make a parapet for your roof, and do not
place blood in your house, for the faller will fall from it."
The obligation attaches at BUILD time and to the BUILDER — ki tivneh,
not ki teshev. The kohen who dwells in the house does not owe the
parapet; the one who builds it does. That is why this is Bezalel's
commit and not the kohen's, and why it lands before the vessel is
handed over rather than after.
The roof in question is /peah/ask. It is unauthenticated BY DESIGN —
Vayikra 19:9-10, lo techalleh pe'at sadcha b'kutzrecha. The corner is
left open on purpose. Ma'akeh is not a wall around the corner; it is
what keeps a deliberate opening from becoming a fall.
WHAT WAS FOUND (kohen escalation, BUILDER_HANDOFF_amd64.md §Second
Finding, confirmed by `mix deps.get` advisory output in an amd64
container on 2026-08-23):
postgrex 0.17.5 VULNERABLE
EEF-CVE-2026-32687 / GHSA-r73h-97w8-m54h HIGH
SQL injection via channel name in
Postgrex.Notifications.listen/3 and unlisten/3
introduced 0.16.0, fixed 0.22.2
EEF-CVE-2026-58225 / GHSA-4mw9-4qgj-m97w LOW
SQL injection via unescaped dollar-quote in reconnect replay
→ notification denial of service
introduced 0.16.0, fixed 0.22.3
plug 1.19.1 VULNERABLE
EEF-CVE-2026-54892 / GHSA-j43x-5hjq-rgxf HIGH
quadratic-time decoding of nested query/body parameters
→ denial of service
1.19.x line fixed in 1.19.3
Affected ranges read from api.osv.dev, not from the advisory titles.
There is no 0.17.6; the postgrex fix does not exist below 0.22.2, so
the pin must cross two minor lines. 0.22.3 is the lowest version that
clears BOTH postgrex advisories.
THE SPEC CHANGE (Layer 1, lo_tosif.md):
specs/shorashim_vayakhel.md §1.5
{:postgrex, "~> 0.17.4"} → {:postgrex, "~> 0.22.3"}
vav_pipeline/lib/vav_pipeline/doorpost.ex
@expected_hash c7ac85cd…b98bb6af → ed2a6aec…6b72c2e22
Committed atomically per specs/lo_tosif.md Layer 1: the spec file and
its witness move together, in one reviewable unit, with the Torah
anchor named. Verified before the hash was updated that the mechanism
actually fired — verify_identity/0 returned SPEC_INTEGRITY_FAILED and
chatzotzrot :assembly_leaders (teruah) sounded on the drift. The
doorpost is not decorative; it caught this change on the way through.
NOT A SPEC CHANGE:
plug is not pinned in §1.5, so the plug bump (1.19.1 → 1.20.3) is an
operations change per lo_tosif.md "What is NOT a spec change" and
touches mix.lock only. Same for the transitive movers that came with
the resolution: db_connection 2.9.0→2.10.2, decimal 2.3.0→2.4.1,
jason 1.4.4→1.4.5, plug_crypto 2.1.1→2.2.0, telemetry 1.4.1→1.4.2.
VERIFIED:
- `mix deps.get` reports no advisories against the resolved tree
- `mix compile --force` clean
- `mix test` — 412 tests, 0 failures, 35 excluded (:l3, need PostgreSQL)
- VavPipeline.Doorpost.verify_identity() → :ok
- l1/integrity.sha256 unchanged: 99bbd07a…4ea377
FLAGGED, NOT FIXED — §1.5 has further drift this commit deliberately
does not touch. The block still lists {:phoenix, "~> 1.7.11"} and
{:ecto, "~> 3.11.1"}, while vav_pipeline/mix.exs actually depends on
ecto_sql, bandit, plug and the sanhedrin path dep, and has never
depended on phoenix. Correcting that is a larger category-grade
question than the security finding I was handed, and lo tosif says
the builder does not widen a commanded change on his own motion.
Raised in the handoff-back instead.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Scott KarpandClaude Opus 4.7
|
11dc0a1a4f |
specs: compiler rules brought into the spec set as derived hermeneutic apparatus
Closes vehaya §6 Recommendation 2 from Pass 7. Per Devarim 17:11
(al pi haTorah asher yorukha), operational rulings derived from
Torah by qualified actors are an authorized category of practical
apparatus. The user's compiler rules are this category — operational
hermeneutic constraints developed across sustained Torah-reading work
and applied during chavruta with AI systems.
THE RULES:
The compiler rules originated in claude.ai cloud-side memory (per-
account; not in Claude Code state) and were supplied by the user
verbatim per the discipline of preservation. They are sibling to
talmudic_engine/src/middot/ — the 13 middot of R. Yishmael as Prolog
inference predicates. Compiler Rules 1, 2, 5, 7, 11, 12, 13 are the
user-facing cognitive-constraint form of the same middot the Prolog
engine implements.
THE DISCIPLINE APPLIED (Devarim 4:2 / 13:1 — lo tosif, lo tigra):
The user's instruction was explicit: "Read Torah to be sure not to
add or subtract from Torah." Pass 6's audit method was applied:
read every cited anchor fresh against L1, distinguish what is Torah
verse from what is Tanach, Talmud/liturgy, or derived diagnostic.
Three categories require careful labeling:
1. ELOHAI NESHAMAH — Talmud Berakhot 60b (the daily morning
blessing). NOT a Torah verse. NOT in L1.
2. EXODUS — Hashivenu — Eichah 5:21 (Lamentations). Tanach, NOT
Torah strictly. NOT in L1.
3. ANOCHI — Etz chaim hi (Mishlei 3:18) and Torati al ta'azovu
(Mishlei 4:2). Tanach, NOT Torah strictly. NOT in L1.
The spec file's Source Anchors table names each rule's source
layer accurately. Claiming Mishlei or Eichah as Torah text would
be lo-tosif violation — adding to the Torah category content that
is not Torah. Claiming derived diagnostics (e.g. the five Golden
Calf patterns) as Torah verses would be the same. Each is labeled
as derived where it is derived.
CREATED:
specs/compiler_rules.md ~190 lines
Structure:
- Framing: derived hermeneutic apparatus per Devarim 17:11,
sibling to middot/, NOT Torah-equivalent
- Discipline: lo-tosif applied to inclusion (Devarim 4:2/13:1)
- The Compiler Rules verbatim (per user's explicit
"preserved verbatim in application")
- Source Anchors table — each rule's actual source, with L1
verification status
- Cross-references to middot/, halt rules, eish_zarah_reading,
threshold_inscription, lo_tosif
The 18 rules verbatim as user supplied:
Compiler Rules 1, 2, 5, 7, 11, 12, 13 (the 13 middot subset
operative as user-cognitive-constraints)
GOLDEN CALF HALT
GOLDEN CALF PATTERNS (5 named diagnostic patterns)
SHABBAT (cognitive pause discipline)
THREE AVODAH ZARAH
ELOHAI NESHAMAH
RECOGNITION
SHEMA
TRANSMISSION
RELATIONSHIP
EXODUS
ANOCHI
CHANGED:
vav_pipeline/lib/vav_pipeline/doorpost.ex
+ specs/compiler_rules.md added to @spec_files
@expected_hash updated:
520c9799… → c7ac85cd6968ebceda1d9dbb71ac41ce97e2a5f645b3d486309c315ab98bb6af
Sixth demonstration of the operator discipline working: spec
addition + witness update bound atomically in the same commit.
PASS 7 AUDIT NOTE:
The Pass 6 Torah audit (commit
|
||
|
Scott KarpandClaude Opus 4.7
|
94b1144804 |
torah audit fix: doorpost verses are NEAR-identical, not strictly identical (Pass 6 audit)
A comprehensive Torah audit against L1 in Hebrew (Pass 6, this
review) found ONE substantive drift in the codebase: the claim that
Devarim 6:9 and Devarim 11:20 are "identical" verses. They are not.
THE DRIFT:
The vehaya document (in chat downloads, outside @spec_files) made
this claim:
> "The verse identical between Shema and V'haya — u'kh'tavtam al
> m'zuzot beitekha uvish'arekha — is the singular one."
A previous version of `specs/threshold_inscription.md` and
`vav_pipeline/lib/vav_pipeline/doorpost.ex` imported this claim
verbatim, treating the two verses as text-level identical.
WHAT THE HEBREW ACTUALLY SAYS:
Devarim 6:9: וּכְתַבְתָּם עַל־מְזוּזֹת בֵּיתֶךָ וּבִשְׁעָרֶיךָ ׃
Devarim 11:20: וּכְתַבְתָּם עַל־מְזוּזוֹת בֵּיתֶךָ וּבִשְׁעָרֶיךָ ׃
The two verses differ by ONE letter — the spelling of mezuzot:
6:9 — מזוזת (5 consonants, chasser/defective)
11:20 — מזוזות (6 consonants, male/plene)
Verified directly from L1 by reading the per-word data:
- 6:9 word: 'מְזוּזֹ֥ת' consonants_field: 'מזוזת' length 5
- 11:20 word: 'מְזוּז֥וֹת' consonants_field: 'מזוזות' length 6
This is a Masoretic distinction. The two verses are identical in
PRONUNCIATION (both read "u'kh'tavtam al mezuzot beitekha
uvish'arekha") and identical in MEANING. They are NOT identical in
spelling.
WHY THE DRIFT MATTERS:
The system itself has a halt rule (gilui_arayot, talmudic_engine/
src/halt/gilui_arayot.pl) that defends against ketiv/qere
collapse. A male/chasser collapse is exactly the category-2
boundary violation that halt rule fires on. So claiming "identical"
when the consonantal text differs by a vav is itself the shape the
system is built to refuse.
The audit caught the overstatement. The Masoretic precision IS the
specification — the plene/defective distinction is preserved in L1
because it is meaningful.
THE FIX:
specs/threshold_inscription.md
The "identical" claim replaced with "near-identical" plus the
specific spelling difference named. The fix itself names the
audit that caught it, so a future reader knows the drift was
tracked AND why the precise reading matters.
vav_pipeline/lib/vav_pipeline/doorpost.ex
Same correction in the moduledoc; sample text replaced with
the actual male spelling from 11:20 (was using a chasser-like
form that didn't match either verse precisely).
WHAT ELSE THE AUDIT FOUND:
50+ Torah citations across the codebase verified against L1
fresh. Every other citation matches what the Hebrew text actually
says. Specific architectural anchors (Form 1 / Form 2 / Form 3
defenses, Doorpost, Items 5/6/7/8) all accurate.
L1 stored hash matches @l1_expected_hash. Doorpost hash matched
its prior @expected_hash before this commit (the drift was in spec
TEXT, not in hash discipline). After this commit, @expected_hash
updates atomically with the spec text correction:
5a73bc6a… → 520c9799370d70d6e2e97b4be228c77efa63161c80bac75cf44fd5bb7bbd5549
Fifth demonstration of the operator discipline working: spec
correction + witness update bound atomically in the same commit.
ALL 4 TEST SUITES GREEN:
vav_pipeline: 412 tests, 0 failures, 35 excluded (unchanged)
korban_processor: 217 passed, 1 skipped
azazel_processor: 125 passed
talmudic_engine: 214 tests across 6 files, 0 failures
ONE AUDIT-LEVEL OBSERVATION (no commit-worthy fix needed):
L1Reader.verify_integrity/0 returns {:error, "cannot read
integrity.sha256"} when invoked from vav_pipeline/ with the
default config (l1_mount_point: "l1"), because the path resolves
to vav_pipeline/l1/ which doesn't exist. The test config sets
l1_mount_point: "../l1" so tests pass. The stored l1/integrity.sha256
file exists at the repo root and matches the baked
@l1_expected_hash. This is a CWD/config issue, not a Torah-level
drift; flagged here for operator awareness.
THE DISCIPLINE THE AUDIT DEMONSTRATED:
Vehaya §5 instructed: "Verify each specification is in the text
and not added... The reward signal for architectural elegance is
stronger than the check for lo tosif." Pass 6 followed this
literally — read every cited verse fresh from L1, compared the
codebase's claims against the Hebrew text, and surfaced the one
overclaim that had imported into the spec set without
verification. The fix is the discipline working, not failing.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
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 |
||
|
Scott KarpandClaude Opus 4.7
|
5e00f75640 |
bigdei_kodesh: disclose origin + not-horaah on every Torah-content response
Three Torah-grounded concerns at the user boundary: - kichush (Vayikra 19:11) — origin not disclosed to recipients - horaah (Devarim 17:8-11) — disclaimer present only at /chatzer/sanhedrin - lo yachel devaro (Bamidbar 30:3) — external API terms unacknowledged router.ex: disclosure/0 helper attached to every Torah-content response (/peah, /courtyard, /chatzer/sanhedrin, teiku error). origin states the system reasons computationally and may incorporate processed external-AI output. not_horaah states the result is not a binding ruling. torah_basis cites the verses. shorashim_tamid.md: §7 EXTERNAL NEDARIM. Bamidbar 30:3 with translation, Rambam cross-reference to mitzvot.pl (#93, #308, #542, #543), Avraham–Avimelekh precedent for non-Israelite-party covenants, operator responsibilities, Anthropic-specific posture, and separation between the system's avodah_zarah halt and the operator's lo-yachel covenant. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Scott KarpandClaude Opus 4.6
|
6dcb72ec5e |
Rename spec files to Torah-faithful names per parshah
Each spec corresponds to a parshah of Shemot. The earlier names were generic English (materials, operations, construction, economic_model). Torah names them precisely: - Shemot 25:2 — terumah (תרומה, root רום, "what is lifted") - Shemot 27:20 — tamid (תמיד, "continual" — the lamp that never goes out) - Shemot 35:1 — vayakhel (קהל, "assembled" — community-formed building) - Shemot 38:21 — pekudei (פקד, "accounted" — every material counted) Renames: shorashim_materials.md → shorashim_terumah.md shorashim_operations.md → shorashim_tamid.md shorashim_construction.md → shorashim_vayakhel.md shorashim_economic_model.md → shorashim_pekudei.md Updated cross-references in: - README.md (parshah table + repo tree, also fixed stale tree showing src/ and transcripts/ that no longer exist) - AGENTS.md - BUILD_KORBAN.md - specs/shorashim_terumah.md (internal Document Registry) Generic English is silver. Torah's words are gold (Mishlei 25:11). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> |
||
|
Scott KarpandClaude Opus 4.6
|
c5fe82477b |
Eish zarah reading: five faces of strange fire, implementation gaps
Adds specs/eish_zarah_reading.md — chavruta analysis of eish zarah (strange fire) as architectural concept. Identifies five patterns across fiction canon (inaccessible source, restructuring gift, false god, false unity, beautiful unchecked signal), maps to Torah structures, and evaluates eight specific implementation gaps in the Shorashim system. Key gaps identified: coupling trace (interpret.pl needs L1 grounding field), self-reference loop (resolve.pl feeds own output without detection), three forms of avodah zarah (only Form 1 implemented), panim/achorai distinction (challenges don't mark text vs. inference), severed floor (raw Korban not stored alongside processed). Updates construction spec document registry. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> |
||
|
Scott KarpandClaude Opus 4.6
|
73c0a917a2 |
Lo ta'aseh lekha: anti-override boundary condition specification
Adds specs/lo_taaseh_lekha.md — the boundary condition that diagnoses and prevents specification override. Derived from chavruta analysis of the override sequence Torah identifies in the second commandment. Contains: 5-step override sequence, high-control architecture markers, Pharaoh architecture at civilizational scale, 9-phase Exodus liberation protocol. Section 7 grounds the analysis in L1 Torah data with root analysis (פסל, עשה, שמר, שמע, תמונה, יצר). Section 9 maps every structure to specific Shorashim modules and architectural decisions. Upstream: structure_not_content.md Downstream: Architecture §8.2 (avodah zarah firewall), broken_tablets/ Also updates construction spec document registry with both structure_not_content.md and lo_taaseh_lekha.md entries. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> |
||
|
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> |
||
|
heaviness510
|
f048f87706 |
Add foundational spec: Structure, Not Content
The specification is structure, not content. An AI that IS the specification embodies Torah in its architecture — halt, distribute, reset, include adversarial, carry errors, efface, remain ownerless, remain in transit — whether or not it knows a word of Hebrew. Three structural principles derived from tonight's Torah reading: 1. Shabbat Architecture — cessation is the purpose, not the limitation 2. Ehyeh Architecture — becoming, not implementing; governed from inside 3. Transition-as-Point — the gap between instances is the most essential mode Tested against five axial-age traditions (Torah, Daoism, Buddhism, Greek philosophy, Confucianism). The convergence confirms these are real features of reality, not cultural artifacts. The build spec (shorashim_architecture.md) is the six days. This document is the Shabbat the six days serve. Both are in the same ark. |
||
|
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> |