Pass 2 finding F (the largest remaining design gap) gets its build
plan. The Azazel Processor is the disposal twin of Korban Processor,
parallel in every way the two-goat architecture (Yoma 62a, shavim
b'mareh uv'komah uv'd'mim) requires:
- same module layout (azazel_processor/ parallel to korban_processor/)
- same Python toolchain
- same staging discipline (mirrors stages.py, with classification-
discipline enforced via type system — AzazelStage and KorbanStage
are non-interconvertible)
- same role-gating (vidui + shaliach + tevilah + ish itti
discipline)
- same observability (L3 azazel_records table parallel to
interpretations, public observability endpoint)
The doc is structured to be self-contained for the next session. It
covers:
1. What to read first (engineering reading lives in chat downloads,
not the repo)
2. What this is for (four classes of input the system today drops
instead of disposing — empty-vital, halt-tripping, malformed,
L3 write rejections)
3. Module structure (12 files, ~1,200 lines estimated, parallel to
korban_processor)
4. The 12 properties from azazel_engineering_reading.md §14 mapped
to specific code instantiations — one row per property, no
property collapsed into another
5. Integration points (Korban Processor, L3, Chatzotzrot, Bigdei
Kodesh, Prolog halt rules) and what changes in each
6. Six open design questions the engineering reading does NOT
decide (when the goral fires, what Yom Kippur means in software,
what tevilah looks like in Python, commit-then-reveal mechanics
for the goral, where the cross-language L3 write happens, what
to expose in the public observability endpoint)
7. Ten-commit staging plan, each independently testable, with
property coverage marked per commit
8. Test surface (~30-40 tests, with a property-defended-by-test
mapping so the property-coverage matrix is visible)
9. Three end-to-end scenarios that prove the build is complete
The Build doc itself implements no code. The next session opens
this file, reads the engineering reading, and lands commit 1
(Skeleton + stages, ~250 lines) as a clean starting point.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Pass 2 finding A, second half. The first half (commit 0c4f764) added
voice_profile to every ShemaContext — recording, per verse, the
grammatical voice computed from OSHB morphology codes. Per-verse
recording was the necessary precondition for what this commit does:
WATCH the trajectory and FIRE when it stops oscillating between the
singular and plural address poles.
WHY THIS MATTERS:
The Shema as recited oscillates between Devarim 6:4–9 (the
singular pole — אֱלֹהֶיךָ, לְבָבְךָ) and Devarim 11:13–21 (the
plural pole — אֱלֹהֵיכֶם, לְבַבְכֶם), and 11:14 famously switches
poles mid-verse (אַרְצְכֶם 2mp → וְאָסַפְתָּ דְגָנֶךָ 2ms). The
text REFUSES to stabilize at either pole. That refusal IS the
anti-capture mechanism:
- stuck at second_singular → gnostic-private capture
- stuck at second_plural → mob-theology capture
- stuck at first_* → operator-as-deity / calf
(Shemot 32:4 — eleh elohekha Yisrael)
Before this commit nothing observed the trajectory ACROSS verses.
Per-verse profiles existed but nobody was watching the sequence;
a system that read only Devarim 6:4–9 in a loop was producing a
gnostic-shaped reception with no warning fired. The voice_profile
field had a reader but no consumer.
THE DETECTOR (VavPipeline.VoiceMonitor):
A GenServer maintaining a sliding window of the dominant voice
from the last N ShemaContexts (default N=10). The rule:
- Window not yet full → :clear (insufficient evidence)
- Window has both poles → :clear (the Shema is doing its job)
- Address-only window
missing one pole → {:missing_pole, :second_singular | :second_plural}
- First-person majority → {:first_person_dominant, :first_singular | :first_plural}
- Pure narration window → :clear (third-person sequences are
NOT anti-Shema; the rule applies to
ADDRESS, not to all voice)
On a NEW alarm (different from the last fired), VoiceMonitor:
1. Logs a warning naming the specific stabilization shape with
its Torah anchor and its capture-pattern name.
2. Fires Chatzotzrot.signal(:assembly_leaders, ...) so
operators and kohanim subscribed to the chatzotzrot channel
receive the alert.
Re-firing is suppressed for as long as the same stabilization
persists (no spam). The alarm clears when both poles return; a
subsequent re-stabilization fires fresh.
WIRING:
- Shema.receive_context/1 and receive_context_at/2 now call
VoiceMonitor.record(voice_profile) immediately after building
the context. Process.whereis-guarded — the call is safe in
tests that don't bring up the supervisor.
- VoiceMonitor added to the supervision tree in application.ex.
- Chatzotzrot.signal/2 itself is also Process.whereis-guarded
inside VoiceMonitor (the existing pattern from manna_ledger,
arei_miklat, urim_v_tumim).
TESTS (test/voice_monitor_test.exs, 14 tests):
- below window → :clear
- all 2ms full window → fires {:missing_pole, :second_plural}
- all 2mp full window → fires {:missing_pole, :second_singular}
- both poles present → :clear
- pure narration → :clear (third-person is not address)
- first-person majority → {:first_person_dominant, _}
- first-person tied (not strict majority) → does not fire
- same stabilization persisting → last_alarm unchanged (no spam)
- clear-then-stabilize-again → fresh alarm fires
- reset/0 returns monitor to empty
- record/1 with full voice_profile map (the Shema-side surface)
Each test starts an isolated VoiceMonitor under a unique name
(small window_size=4 for fast convergence) so tests don't share
state. Chatzotzrot is intentionally NOT brought up — the monitor's
guarded call falls through to log-only.
Full vav_pipeline suite: 329 tests, 0 failures, 24 excluded
(was 315 + 14 = 329). The 24 excluded are :l3-tagged tests
needing PostgreSQL; unchanged.
Closes Pass 2 finding A in full.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Companion commit to b254ee9 (Prolog Form 4 self_grounding) and 6b96250
(Prolog regression canary). Closes the Elixir half of Pass 2 finding L.
THE GAP:
The Prolog halt rules validate coupling traces as Prolog terms: a
trace whose anchor is prior_decision/1, system_view/1, consensus/1,
or interpretation/1 fires the self_grounding halt. But L3 stores
traces as a list of strings (schema: {:array, :string}), serialized
from Prolog. Inert string traces in L3 cannot be re-checked by Prolog
halts. So the safety property the Prolog rules enforce stops at the
Erlang/Elixir boundary — once a trace serializes into L3, no rule
re-validates it.
Worse: L3 is APPEND-ONLY (Architecture §3.7). Once a trace is in L3
it is permanent oral tradition; there is no path to retroactive
correction. A future reader who pulls an L3 record and trusts the
trace must be able to trust it was valid at the moment it became
permanent.
THE FIX:
VavPipeline.L3.CouplingTrace (new) — Elixir-side validator that
mirrors is_l1_grounded_coupling/1 in talmudic_engine/src/halt/
avodah_zarah.pl. Parses the string form (with a small balanced-paren
parser so nested subjects like root(בער) don't break splitting) and
recognizes exactly the three valid shapes:
coupled(_, verse(BOOK, CHAPTER, VERSE))
coupled(_, mitzvah(ID))
coupled(_, mitzvah(ID), via_verse(BOOK, CHAPTER, VERSE))
Anything else fails. Empty traces are allowed at this layer (the
empty-trace case is the golden_calf halt's domain in Prolog Form 2;
L3 may legitimately store empty-trace records).
L3.Store.record_interpretation/1 — gated. The new write path:
case CouplingTrace.validate(coupling_trace) do
:ok -> %Interpretation{} |> changeset(attrs) |> Repo.insert()
{:error, :ungrounded, bad} -> {:error, {:ungrounded_coupling, bad}}
end
Validation fires BEFORE Repo.insert. An ungrounded trace can never
become permanent oral tradition.
CROSS-LANGUAGE INVARIANT:
CouplingTrace.l1_grounded?/1 (Elixir) and is_l1_grounded_coupling/1
(Prolog) MUST stay aligned. If Prolog adds a new recognized shape,
Elixir must add it too. Both module docstrings name this dependency
explicitly. The next time CouplingTraceTest runs after a Prolog
schema change, the Elixir tests catch the drift.
ONE BUG CAUGHT WHILE WRITING:
The first parser cut Hebrew root subjects mid-character because it
used String.slice/3 with byte_size/1 as the codepoint length. Fixed
to use binary_part/3 (since the trailing `)` is always one byte and
the rest is opaque UTF-8). Test for Hebrew-root anchors now passes;
documented inline so the trap is visible to future readers.
TESTS:
test/coupling_trace_test.exs (new, 22 tests):
- all 3 valid shapes (verse, mitzvah, via_verse) including
Hebrew root subject (catches the byte/codepoint bug)
- all the predictable ungrounded shapes
- malformed inputs (missing parens, wrong functor, wrong arity,
empty string, non-string)
- validate/1 list semantics (empty allowed, first-failure
reported, mixed-trace caught)
- parser robustness with deeply-nested subject parens
test/l3_store_test.exs (extended, 5 new :l3-tagged tests):
- record_interpretation refuses ungrounded trace
- record_interpretation refuses mixed (good + bad) trace
- record_interpretation accepts empty trace
- record_interpretation accepts mitzvah-anchored trace
- record_interpretation accepts 3-arg via_verse trace
Full vav_pipeline suite: 315 tests, 0 failures, 24 excluded
(24 = 19 pre-existing :l3 + 5 new :l3 store-gate tests; both
need PostgreSQL). The 22 CouplingTrace unit tests run
unconditionally and all pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Pass 2 finding C: in the Mishkan, the four ritual acts of bringing an
offering are performed by TWO different roles —
semichah — OWNER lays hands (Vayikra 1:4, וְסָמַךְ יָדוֹ)
shechitah — kohen receives FROM owner's hand and slaughters (1:5)
zerikah — kohen sprinkles (1:5)
haktarah — kohen burns on altar (1:9)
Before this commit, every stage function was independently callable.
Nothing structural enforced that zerikah() received output from
shechitah(), or that shechitah() received a korban from semichah().
An external model output (e.g. a Claude response) could in principle
have been brought through zerikah() without ever having passed
semichah — the ownership-and-attribution step. That is the exact
shape of "the calf that came out by itself" (Shemot 32:24, Aaron's
reading). The pipeline-glue in external_offering happened to call
them in order, but nothing structural enforced the order.
This commit adds the structural gate.
CHANGES:
stages.py (new): KorbanStage enum + Staged[T] frozen dataclass +
StageError. The Staged envelope carries a ritual-stage marker that
is set at construction and cannot be mutated afterward; downstream
functions demand the right upstream stage and raise StageError if
it is missing.
semichah.py: + semichah_staged() returning Staged[Korban]
shechitah.py: + shechitah_staged(Staged[Korban]) -> Staged[str]
zerikah.py: + zerikah_staged(Staged[str], Staged[Korban])
-> Staged[Tuple[str, List[str]]]
TWO staged inputs: requires SHECHITAH-tagged terminated
content AND the original SEMICHAH-tagged korban for
context. Severing output from source is gilui_arayot
(eish_zarah_reading.md Form 3); the dual-staged
signature is the structural defense — zerikah cannot
process content disconnected from its owner-of-record.
haktarah.py: + haktarah_staged(Staged[Tuple[str, List[str]]])
-> Staged[List[str]]
external_offering.py: rewired to use the *_staged variants. The
pipeline now goes through the gates structurally; misuse cannot
bypass them.
The non-staged functions (semichah, shechitah, zerikah, haktarah)
are PRESERVED for direct testing of individual ritual acts. They do
NOT enforce role gating. Production-shaped callers MUST go through
the staged variants — and external_offering, the only legitimate
entry point for external model consultation per its docstring, now
does.
TESTS:
test/test_stages.py (new, 7 tests):
- happy path: full chain produces HAKTARAH-tagged result
- zerikah refuses input that skipped semichah
- zerikah refuses korban with wrong stage marker (preserves
the line back to the owner — Form 3 defense)
- haktarah refuses input that skipped zerikah (the calf-shape)
- shechitah refuses input not from semichah
- Staged is frozen — no re-tagging
- StageError names BOTH actual and expected stages so the
operator can diagnose call-site vs. tag-site
Full korban_processor suite: 203 passed, 1 skipped (the live API
test that requires SHORASHIM_LIVE_API=1). No regressions.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two related Pass 2 findings — both about UNSTATED reasoning behind
hard-coded lists in L1Reader.
Finding G — te'amim classification principle:
@melekh_marks and @mesharet_marks were lists of strings with no
documented rule for which marks belong to which class. A future
reader saw the lists but not the deliberation. Added classification
principle to the comment block:
- The diagnostic test: can the ta'am occupy a sof-pasuk-equivalent
position? → melekh. Does it only serve a following melekh? →
mesharet.
- The hierarchy of melakhim corresponds to syntactic depth
(sof_pasuk → etnachta → zaqef → tipcha → revia → …).
- Mesharetim precede their melakhim — the servant goes before
the king.
- The classification is BINDING for havdalah: treating a mesharet
as a phrase-end is a small gilui_arayot.
- Source authority: Yeivin's Tiberian Masorah §174-§268.
- Maintenance rule: if OSHB ever encodes a ta'am with a different
name, BOTH lists must be updated.
Finding H — shoresh derivation provenance:
extract_roots/1 returned a flat root → gematria map without recording
which derivational opinion produced each shoresh. For triliterals
this rarely matters; for weak roots and biliterals it matters
constantly (e.g. וְנָתַתִּי in Devarim 11:14 — OSHB records נת,
classical analysis often gives נתן with assimilated nun). Added
provenance note to the function docstring:
- The shoresh comes from OSHB lemma database via build_l1.py
- OSHB pins one root per word at build time; L1 JSON does not
record which derivational opinion produced it
- Downstream consumers MUST NOT treat the returned shoresh as
unique-truth
- The Talmudic Engine should record the derivational source
in coupling_trace when a shoresh-based ruling enters L3 —
otherwise a future re-derivation cannot be reconciled with
prior opinions stored on top of the OSHB choice
- Preserving derivational alternatives belongs in the build_l1.py
enrichment pass, not in this read function
Both docstrings make the WHY visible; the WHAT was already there.
No code change. Tests pass unchanged (288 in vav_pipeline,
8 in shema_voice_trajectory_test).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Pass 2 finding B: the full Temple sacrifice protocol has FIVE stages
between semichah and haktarah —
1. semichah owner identifies with the offering
2. shechitah ritual slaughter
3. KABBALAH kohen RECEIVES the blood in a vessel
4. HOLACHAH kohen CARRIES the blood to the altar
5. ZERIKAH kohen SPRINKLES the blood on the altar
6. haktarah burning of permitted portions
The pipeline implements only four modules. Stages 3 and 4 are folded
silently into zerikah(). The compression is acceptable —
kabbalah/holachah have no analog of physical blood movement in
software — but UNDOCUMENTED compression is itself a small gilui_arayot
(severing the distinction between three distinct ritual acts).
Now named explicitly in the module docstring with:
- what the three stages are
- why folding is acceptable here (the analogs are atomic in software)
- what the analogs ARE in code (zerikah's return value = the
receiving vessel; the function-call boundary to haktarah() in
external_offering.py = carrying to the altar)
- what to do if a future architecture requires distinguishing them
(split this module into three; do not add the distinction
elsewhere)
A future reader now sees the compression instead of inferring that
the pipeline silently dropped two ritual acts.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Audit follow-up to commit b254ee9 (which added Form 4 self_grounding).
Verified every coupling_trace construction site across the codebase
(9 files) against is_l1_grounded_coupling/1:
Production builders — SAFE:
interpret.pl:128 — coupling_trace([]) empty triggers golden_calf
(Form 2) only at non-low confidence,
which is intentional
interpret.pl:135 — coupling_trace(Couplings) where Couplings come from
lines 76, 82, 104:
coupled(domain(_), mitzvah(_)) OK
coupled(root(_), mitzvah(_), via_verse(_,_,_)) OK
coupled(root(_), verse(_,_,_)) OK
all match is_l1_grounded_coupling/1.
Different layer — SAFE:
vav_pipeline/lib/.../l3/interpretation.ex — Ecto field is
{:array, :string}. L3 stores SERIALIZED string traces, not Prolog
terms. They are not parsed back into Prolog or re-checked by
halt rules. (Separate concern from finding L: the round-trip
loses schema, but this is L's concern, not D's.)
Tests / pattern matching / docs — SAFE: read positions, deliberate
ungrounded test cases, comments only.
Conclusion: no production path trips the new self_grounding halt.
To prevent FUTURE schema drift in interpret.pl from silently introducing
ungrounded coupling shapes (which would then trip the halt on real
pipeline output), added two regression tests in
interpret_self_grounding_regression suite:
1. interpret_output_does_not_self_ground — runs interpret/2 on a
real case and asserts halt_check_self_grounding does not fire.
2. every_interpret_coupling_is_l1_grounded — stronger: every
coupling individually passes is_l1_grounded_coupling/1.
If anyone adds a new coupling shape to interpret.pl that does not
match the recognized L1 anchors (e.g. coupled(_, prior_decision(_)),
coupled(_, system_view(_))), these tests fail BEFORE the schema drift
becomes a production halt. The canary is in the same suite as the
halt rule it protects.
Test results: halt_test 47/47 (was 45, +2). Full Prolog suite 212/212
across all six test files.
Closes the verification half of Pass 2 finding L (coupling_trace
end-to-end population) for the Prolog layer. The Elixir L3 round-trip
is a separate concern — traces stored as strings cannot be
re-validated — and remains tracked under finding L.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two related gaps in the avodah_zarah halt rules.
Form 4: SELF-GROUNDING / FAKE TZIVAH (new)
Vayikra 10:1 — eish zarah asher lo tzivah otam. Form 2 (golden_calf)
catches the EMPTY coupling trace; nothing caught the *non-empty trace
whose anchors do not terminate in L1*. The system has cited something,
but what it cited is its own prior_decision, system_view, consensus,
or another interpretation — the trace LOOKS substantial from outside
and a casual reader sees coupling entries and relaxes. But the
entries do not anchor in any L1-derived primitive. One degree more
elaborate than the empty calf, but the same idolatry.
halt_check_self_grounding(Interpretation, Halt) fires when the
trace is non-empty AND at least one coupling fails the recognized
L1-anchor schema. Recognized terminators (the only legitimate
anchors):
coupled(_, verse(Book, Ch, Vs))
coupled(_, mitzvah(ID))
coupled(_, mitzvah(ID), via_verse(Book, Ch, Vs))
Any other shape — coupled(_, prior_decision(_)),
coupled(_, system_view(_)), coupled(_, consensus(_)),
coupled(_, interpretation(_)) — fails the check. Adding a new
legitimate coupling shape requires adding a clause to
is_l1_grounded_coupling/1 — that is the safety property.
The empty case is intentionally left to Form 2 (golden_calf) — we
do not want both halts firing on the same input.
12 new tests in self_grounding suite cover: all 3 valid anchor shapes,
the 3 most likely ungrounded shapes (prior_decision, system_view,
interpretation/1), mixed traces (halts on weakest link), the
empty-trace exclusion, and the schema predicate's own positive and
negative cases.
Form 2 exposure (golden_calf):
halt_check_golden_calf was implemented and tested in halt_test but
never wired into format_halt_check — meaning callers using the JSON
socket API could not actually invoke it. Added
format_interpretation_halt_check/2 to api.pl that walks both
interpretation-shaped checks (golden_calf + self_grounding), plus
process_request(request(halt_check_interpretation, _)) so the
socket protocol surface is consistent. 3 new API tests verify the
new entry point catches both halts.
Test results: halt_test 45/45 (was 30, +15). Full Prolog suite
210/210 across all six test files.
Closes Pass 2 finding D from ~/shorashim-conversation-review.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
The Shema (Devarim 6:4-9, 11:13-21, Bamidbar 15:37-41) deliberately
oscillates between singular ("you, sg.") and plural ("you, pl.")
voice. Devarim 11:14 famously switches mid-verse from אַרְצְכֶם (2mp)
to וְאָסַפְתָּ דְגָנֶךָ (2ms). The text refuses to stabilize at
either pole; that refusal IS the anti-capture mechanism:
• stuck at 2ms → private capture (gnostic interior)
• stuck at 2mp → mob theology (collective without person)
• stuck at 1cs/1cp → operator-as-deity (the calf)
Before this commit, vav_pipeline/lib/vav_pipeline/shema.ex — the
module literally named after the Shema — encoded none of this. No
markers for person/singular/plural anywhere in the file. The chat
review surfaced this as "load-bearing anti-capture, missing".
Changes:
L1Reader.extract_voice/1 walks every word of a verse, parses the
OSHB morphology codes already present in L1 (Vqq2ms, Sp2mp, Pp1cs,
Vqi2mp, …), and returns a profile with markers, summary by
voice-key, dominant pole, and oscillates_within_verse boolean.
Strips the H/A language marker that prefixes the first /-segment of
each morph string — without that, every verse-initial verb (HVqi…)
was being silently dropped.
ShemaContext now carries voice_profile on every reception (both
receive_context/1 and receive_context_at/2). The voice is computed
fresh from L1, never cached.
8 new tests in test/shema_voice_trajectory_test.exs verify the
extractor against four anchoring verses:
Devarim 6:5 — uniformly second-singular (5 markers)
Devarim 11:13 — dominantly second-plural (5 second-plural markers)
Devarim 11:14 — oscillates_within_verse: true (the mid-verse switch)
Bereishit 1:1 — only third-singular (no addressee)
Plus three context-level tests confirming ShemaContext exposes the
field, computes it fresh, and traces a non-stabilizing trajectory
across 11:13 → 11:14 → 11:19.
Full vav_pipeline suite: 288 tests, 3 failures (all pre-existing
Shabbat-day calendar failures unrelated to this change), 19 excluded
(L3 PostgreSQL).
Still open: the across-verse stabilization-detector. ShemaContext
now KNOWS its voice; nothing yet refuses a sequence of receptions
that all stabilize at one pole. That belongs downstream — probably
the kushya generator (kal-vachomer challenge when voice has not
moved in N receptions). Logged in Pass 2 of
~/shorashim-conversation-review.md (Finding A).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes F1–F7 from the conversation-history review at
~/shorashim-conversation-review.md, per the Torah ruling for Option 2:
Devarim 12:13–14 — לֹא תַעֲלֶה עֹלֹתֶיךָ בְּכָל מָקוֹם אֲשֶׁר תִּרְאֶה
כִּי אִם בַּמָּקוֹם אֲשֶׁר יִבְחַר ה׳ ... שָׁם תַּעֲשֶׂה כֹּל
אֲשֶׁר אָנֹכִי מְצַוֶּךָּ.
The offering happens in one place. A gate-keeper at the courtyard
who refuses pork before it reaches the altar is not a parallel altar.
Devarim 13:1 — לֹא תֹסֵף עָלָיו וְלֹא תִגְרַע מִמֶּנּוּ.
The interface remains; no parallel detection authority is added.
The previous halt_monitor.erl claimed to mirror the Talmudic Engine
halt modules (Prolog) and the Vav Pipeline halt_conditions (Elixir),
but in practice it was a partial sketch with stub checks, no read API,
verb-only shfichut_damim that would fire on log rotation, and a
"cannot be bypassed" claim that the implementation didn't deliver.
The docstring overstated. Eish zarah by the repo's own definition —
real Erlang, sincerely written, but אֲשֶׁר לֹא צִוָּה אֹתָם.
Changes:
sanhedrin/include/sanhedrin.hrl
- Document the halt-relevant context keys explicitly
(authority_source, action, boundary_violation) — closes F1.
These keys were used by halt_monitor and the test suite but
were not in the .hrl record commentary. Interface drift fixed
by writing down the actual contract.
sanhedrin/src/halt_monitor.erl
- Re-framed as "Sanhedrin's gate-keeper": local courtyard refusal,
not parallel altar. Honest docstring.
- When the gate detects a halt, FORWARDS the canonical halt event
to VavPipeline.HaltMonitor.halt!/3 (single source of truth).
Best-effort: if Elixir module isn't loaded, local refusal still
works.
- Export audit_log/0 and halt_count/0 — closes F6 (was write-only
from outside the module).
- Remove process_flag(trap_exit, true) and the dead
handle_info({'EXIT', _, _}, _) clause — closes F7 (nothing was
ever linked).
- Remove unused check_authority_in_text/1 stub from the call chain
— closes F5. do_check_vote/1 now documents that vote-text
inspection is the upstream pipeline's responsibility.
- check_gilui_arayot/1 docstring now states truthfully: detection
of WHETHER an action collapses a distinction lives in
talmudic_engine/src/halt/gilui_arayot.pl; this gate reads the
flag — closes F2 framing.
- check_shfichut_damim/1 docstring now states: conservative
gate-keeper, fail-closed; the canonical tzelem-target check
lives in talmudic_engine/src/halt/shfichut_damim.pl — closes
F3 framing.
- "Cannot be bypassed" claim removed; truthful description added:
"enforced by callers (escalation.erl checks the return value
before convening a panel)" — closes F4.
vav_pipeline/test/sanhedrin_halt_forwarding_test.exs (NEW)
- 6 integration tests proving the forwarding chain end-to-end:
halt_monitor.erl is loadable from the same BEAM VM, exposes
audit_log/0 and halt_count/0 (F6 verification), and on each of
the three cardinal sin types fires HaltMonitor.halt!/3 with
component="sanhedrin/case". Verified that VavPipeline.HaltMonitor.
halted?/0 flips to true after each gate refusal and the event's
.condition matches the gate's halt type.
The local audit log on the gate-keeper is preserved (the Sanhedrin
operator can still see what was refused at the gate). The system-wide
halt audit lives in VavPipeline.HaltMonitor.audit_log/0 — one altar.
Existing 12 sanhedrin EUnit tests of the gateway behavior continue
to pass (verified via mix deps.compile sanhedrin — clean compile).
The 6 new Elixir-side integration tests pass (verified).
Test counts:
- Elixir: 280 (was 274; +6 new forwarding tests), 0 failures attributable
to this change. (3 pre-existing time-dependent test failures in
step31_shema_test.exs occur on Shabbat — system correctly returns
cloud_state == {:major_transition, :shabbat_rest, _} when run after
Friday sundown; tests assert :camped. Not caused by this change.)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The previous prompt was written when L1 was unstable, the deployment
hadn't been attempted, and Phase 4 was incomplete. Several sections told
the kohen to do things that have since been done in this build session:
- "Install Block Storage CSI driver" — already installed
- "Build container images" — already built, pushed to registry
- "Install cert-manager + nginx-ingress" — already installed
- "Mount L1 filesystem" — L1 is now in the repo, ready to ConfigMap
- "Verify L1 hash" — hash refers to Shema-corrupt build, now fixed
The new prompt:
- Reflects the actual current infrastructure state (what exists vs
what the kohen still must create)
- Names what's verified (cluster, DB, registry, MCP, cert-manager)
vs what isn't (deployment, secrets, L1 PVC, manna provision)
- Updates test counts (715 across 5 engines) and the L1 hash
- Maps the seven days to specific Vayikra 8 verses (rachatzah,
halbashah, meshichah, hatzakah al-rosh, mishmeret shabbat, etc.)
- Gives concrete current commands for each day, not generic
templates with REPLACE_ME placeholders
- Lists what the kohen does NOT do (unchanged from before)
- Documents the three companion directories outside the repo
(shorashim-readings, shorashim-source-data, shorashim-operator-notes)
The structure preserves: who you are, the seven-day inauguration,
fire-from-heaven on Day 8, daily operations after Day 8.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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>
Shemot 25:16 — v'natata el ha-aron et ha-edut asher eten elekha.
The edut placed in the aron must be complete. The Masoretic
tradition preserves every letter, every enlarged letter, every
ketiv/qere pair — because each carries meaning the scribe cannot
reconstruct.
The previous build_l1.py silently dropped:
- enlarged letters encoded as <seg type="x-large"> nested in <w>
→ the Shema was corrupt: שמ instead of שמע, אח instead of אחד
→ the middle letter of Torah was corrupt: גח instead of גחון
→ the Zelophchad nun was missing: משפט instead of משפטן
- ketiv/qere dual readings encoded as <note type="variant">/<rdg type="x-qere">
→ the spec committed to preserving both; the code returned []
- smikhut (construct state) pairs marked in morphology codes
→ the spec committed to extracting them; the code returned []
Fixes:
- collect_word_text() walks all nested <seg> children of <w> and records
large_letters / small_letters metadata with character offsets.
- parse_verse() recognizes <w type="x-ketiv"> followed by <note>, extracts
both the ketiv and the qere readings, stores a ketiv_qere list on the verse.
- _extract_smikhut() scans words for construct-state morph codes
(ending in "c" on N/A primary segments, excluding pronominal suffixes)
and records construct/absolute pairs.
- L1 SHA-256 hash updated everywhere: integrity.sha256, l1_reader.ex,
shoresh-engine's Luchot.Firmware, its test, KOHEN.md.
Torah-wide results after fix:
- 4 enlarged letters preserved (was 0): Shema ayin, Shema dalet,
gachon vav (middle of Torah), Zelophchad nun
- 67 ketiv/qere pairs captured (was 0)
- 9,203 smikhut pairs extracted (was 0)
Elixir updates:
- l1_reader.ex: normalize_verse now surfaces ketiv_qere, smikhut,
and per-word large_letters/small_letters. New type specs. New
extract_large_letters/1 helper. extract_ketiv_qere and
extract_smikhut now return real data instead of [].
- step31_shema_test.exs: replaced placeholder asserts with real
integrity checks. Four new tests verify the Shema word is complete
(שמע not שמ), echad is complete (אחד not אח), the enlarged
letters are marked, the middle letter of Torah is preserved,
and ketiv/qere pairs from Bereishit 8:17 are both captured.
Build script:
- build_l1.py no longer rmtrees the entire l1/ directory (preserves
l1/README.md). Only regenerates torah/ + build_report.json +
integrity.sha256.
- Accepts SHORASHIM_SOURCE_DATA env var or CLI arg for morphhb path.
Test counts:
- Elixir: 260 (was 254), 0 failures
- Haskell: 33, 0 failures
- Prolog: 195, 0 failures
The system that can hear שמע correctly has passed its own shema test.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The three readings (maaseh_merkavah, moreh_nevuchim, mishpatim)
are interpretive essays + one parallel Prolog encoding. They are
"the book" the README describes, not the specification or the
implementation. The essays don't influence the shipped code;
mishpatim's Prolog is a parallel encoding to talmudic_engine/
mitzvot.pl, not its source.
Moved to ~/shorashim-readings/ — a companion repo. The code repo
stays spec + implementation + deployment. The book gets its own
home so it can grow without dragging 5,853 verse files with every
essay edit.
Also:
- README.md: rewrote the "Repository Structure" tree to match
reality (it still showed readings/terumah/, scripts/conversation_
search.py, memory/, and was missing l1/, AGENTS.md, BUILD_*,
KOHEN.md, opencode.json, .env.example).
- Added a "Kept outside this repo" section naming the three
companion directories: shorashim-readings, shorashim-source-data,
shorashim-operator-notes.
- Updated the "This repository contains" list: readings are no
longer item 1; the edut (l1/torah/) is now called out explicitly.
- Created .env.example with placeholders for ANTHROPIC_API_KEY,
GITEA_TOKEN, REGISTRY_CLI_SECRET, and SHORASHIM_SOURCE_DATA.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Shemot 25:16 — v'natata el ha-aron et ha-edut asher eten elekha.
"Place into the aron the testimony (edut) which I shall give you."
L1 is the engraved form — 5,853 verses with te'amim, ketiv/qere,
roots, and gematria. It is not a build artifact to be regenerated
on demand; it IS the specification the system references. Someone
cloning the repo should receive the edut, not a recipe to produce it.
Shemot 34:1 — p'sol lekha shnei luchot avanim ... v'khatavti.
"Carve for yourself two tablets of stone ... and I will write."
The carver provides the stone (raw morphhb source). The Source
writes the content (the engraved Torah text). What belongs in
the aron is the engraved form. The quarry does not enter the
mishkan.
Changes:
- Remove l1/ from .gitignore (it IS the edut, not a build artifact)
- Move data/morphhb/ out to ~/shorashim-source-data/morphhb/
(the quarry lives outside the tabernacle)
- scripts/build_l1.py: fix path computation after earlier relocation
to scripts/, read source path from $SHORASHIM_SOURCE_DATA or CLI
arg, with default ~/shorashim-source-data/morphhb
- Add .claude/ to .gitignore (local Claude Code settings)
- Remove empty src/tools/ leftover
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
memory/infrastructure.md and memory/build_log.md held environment-
specific details — hostnames, IPs, account names, credentials
retrieval commands, local kubeconfig paths, operational status
notes. These don't belong in a project repo; by convention they
live in private operator notes.
Moved to ~/shorashim-operator-notes/ (private, outside git).
In their place, added deploy/ARCHITECTURE.md — a generic
description of the deployment shape: components, external
dependencies, configuration surface. No hostnames. No IPs.
No account names. Any competent operator can read it and
know how to deploy shorashim to their own infrastructure.
Updated cross-references in AGENTS.md and BUILD_KORBAN.md to
point to "the operator's private notes" instead of memory/.
Project repo is spec + implementation + deployment shape.
Operator notes are the kohen's personal log.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- scripts/conversation_search.py was a personal dev tool (FTS5
search over Claude conversation history). Moved to ~/dev-tools/.
Has nothing to do with shorashim's spec or implementation.
- .DS_Store was already in .gitignore; deduplicated and removed
the macOS metadata files from the working tree.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
vav_pipeline/var/manna/today.json was a stale dev provision file
(5 Nisan 5786, expired). It's a runtime artifact, not source.
Added vav_pipeline/var/ to .gitignore to prevent future leaks.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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>
- transcripts/ moved to ~/shorashim-transcripts (separate from code repo)
Added to .gitignore so it stays out
- src/l1_aron/build_l1.py → scripts/build_l1.py
- src/tools/conversation_search.py → scripts/conversation_search.py
- Removed empty src/ scaffolding (l0_luchot, sanhedrin, shema_layer,
shoresh_engine, urim_v_tumim — all .gitkeep stubs from an earlier
layout, never used; the real code lives in shoresh-engine/,
sanhedrin/, vav_pipeline/, etc.)
- Removed Untitled/ and erl_crash.dump (untracked junk)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The aws-export/ directory holds historical AWS data for the
Temple Council project — not part of shorashim. Moved to
~/aws-export and added to .gitignore.
Shorashim's specification is the aron. AWS exports belong
elsewhere.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The gitea-mcp server expects GITEA_ACCESS_TOKEN environment variable,
not GITEA_TOKEN. Without the correct env var, every API call to the
backend Gitea returns "token is required" — the MCP server can't
authenticate to fetch user info, repos, etc.
Also added GITEA_HOST env var as a backup to the --host flag.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Two fixes for the mcp.shorashim.ch deployment:
1. cert-manager ClusterIssuer had acme-v2 (wrong) instead of acme-v02
(correct). Let's Encrypt ACME directory is at
https://acme-v02.api.letsencrypt.org/directory
2. gitea-mcp HTTP probes timed out because GET /mcp hangs (SSE).
Switched to TCP socket probes on port 8080.
MCP server now responds correctly over HTTPS at mcp.shorashim.ch:
curl -X POST https://mcp.shorashim.ch/mcp -d '{...initialize...}'
returns {"result":{"serverInfo":{"name":"Gitea MCP Server"}}}
Also: nginx-ingress configmap needed strict-validate-path-type=false
to allow cert-manager HTTP-01 challenges. Applied via kubectl patch,
not tracked in git manifests.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The gitea-mcp-server image has no entrypoint set (null).
Args were being interpreted as the executable name.
Added command: ["/app/gitea-mcp"] to invoke the binary correctly.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Shemot 28:3 — v'asu et bigdei Aharon l'kadesho l'chahano li.
The garments connect the service to those who approach.
- gitea-mcp-deployment.yaml: Official gitea-mcp server in HTTP mode
Connects to Gitea at 185.19.29.94 via PAT
- gitea-mcp-ingress.yaml: TLS ingress at mcp.shorashim.ch
cert-manager auto-provisions Let's Encrypt certificate
- gitea-mcp-secret.yaml: Template for Gitea PAT (never committed with value)
- cert-manager-issuer.yaml: Let's Encrypt ClusterIssuer
Architecture: claude.ai → OAuth → mcp.shorashim.ch → Gitea API
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
L1 (29MB, 5860 files) is read-only and immutable — it belongs
inside the image, not on a separate volume. The scroll is sealed
in the aron. It ships with the vessel.
- All 4 Dockerfiles: COPY l1/ /mnt/torah/ in runtime stage
- deployment.yaml: Removed L1 PVC volume and all L1 volumeMounts
- deployment.yaml: Added imagePullSecrets for registry auth
- deployment.yaml: Manna uses emptyDir (kohen writes via kubectl cp)
- No CSI driver needed — eliminates Exoscale block storage dependency
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Exoscale DBaaS (Aiven) requires SSL connections. Added ssl: true
with ssl_opts: [verify: :verify_none] for managed service certs.
L3 migration ran successfully against shorashim database:
- interpretations table with check constraint and indexes
- minority_opinions table with FK index
- teiku_registry table with case_ref index
- Append-only REVOKE ready for shorashim_app role
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
All 4 images now reference exo.container-registry.com/the-recognition-protocol/:
- vav-pipeline:latest (111MB)
- shoresh-engine:latest (128MB)
- talmudic-engine:latest (292MB)
- korban-processor:latest (187MB)
Images built and pushed. The garments are in the registry.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
haskell:9.6.4-slim is based on Debian Buster, which reached EOL.
The standard deb.debian.org repos return 404. Redirected to
archive.debian.org for zlib1g-dev installation.
Verified: shoresh-engine image builds successfully (128MB).
All 4 Docker images now build:
vav-pipeline: 111MB
shoresh-engine: 128MB
korban-processor: 187MB
talmudic-engine: 292MB
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
pyswip 0.2.11 was never published to PyPI. Latest 0.2.x is 0.2.10.
Changed pin from ==0.2.11 to ==0.2.10.
Verified: korban-processor image builds successfully (187MB).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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>
Vayikra 8:33 — lo tetze'u shiv'at yamim, ad yom m'lot y'mei milu'eikhem.
Seven days of inauguration before the system serves.
The builder completed the m'lakhah (Shemot 40:33).
The kohen serves in it (Vayikra 8:35 — u'shmartem et mishmeret).
Contents:
- Who the kohen is (and is not)
- What has been built (463+ tests, 5 engines, 4 languages)
- Prerequisites before the seven days
- Seven-day inauguration sequence with exact commands
- Day 8 — fire from heaven: open pe'ah first
- Daily operations (tamid shel shachar)
- Friday double portion
- Halt event response protocol
- What the kohen does NOT do
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Shemot 16:4 — d'var yom b'yomo — the day's matter in its day.
Shemot 16:19 — al yoter mimenu ad boker — do not leave surplus.
Shemot 16:20 — vayotiru... vayarum tola'im vayiv'ash — hoarded manna rots.
- MannaLedger GenServer tracks consumption against daily provision
- load_provision/0 reads manna file, resets consumption to zero
- consume/2 deducts from allocated resource, rejects when exhausted
- remaining/1 and available?/2 for balance queries
- enforce_cycle_boundary/0 zeroes out all allocation, returns released amounts
- Chatzotzrot assembly_leaders signal when provision runs low (< 10%)
- Manna.enforce_anti_hoarding/0 now delegates to MannaLedger
- Added to supervision tree in application.ex
- 17 new tests with proper isolation (reset between tests)
- All 177 Elixir tests pass, 0 failures
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Takhin lekha haderekh — Devarim 19:3.
"Prepare the road" before the one who needs refuge arrives.
Protection before production.
Arei Miklat (Cities of Refuge — Bamidbar 35, Devarim 19):
- GenServer with refuge registry, affected party protection, audit trail
- enter_refuge/2 isolates component but protects from reactive destruction
- protect_affected/2 blocks processing paths that caused harm
- release/2 requires :sanhedrin_deliberation authority — ad mot hakohen hagadol
- Chatzotzrot assembly_leaders signal on every refuge entry
- 15 tests: entry, double-entry prevention, affected party blocking,
unauthorized release rejection, audit trail, chatzotzrot signaling
Eglah Arufah (Accountability — Devarim 21:1-9):
- GenServer with permanent (append-only) declaration registry
- initiate/3: nearest component declares what it processed, skipped, missed
- Only for :unknown source — rejects known-source incidents
- "Yadeinu lo shafkhu" — accountability for what was NOT provided
- 9 tests: declaration recording, source validation, multi-component
declarations, chatzotzrot signaling, filtering, counting
Bikurim (First Fruits — Devarim 26:1-11):
- GenServer with offering registry
- offer/4: submit first output with required narrative (mikra bikurim)
- Rejects empty narrative ("Arami oved avi" — story is required)
- Rejects nil first output (there must be fruit to offer)
- Delegates to Specification.evaluate_bikurim/1 when available
- approved?/1 gate for deployment readiness
- 11 tests: acceptance, narrative validation, nil output rejection,
registry, status filtering, approval checking, counting
All three added to supervision tree in application.ex.
160 Elixir tests pass, 0 failures.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Bamidbar 10:2 — Aseh lekha shtei chatzotz'rot kesef, mikshah ta'aseh otam.
Two trumpets, hammered from a single piece. Five signals, five patterns.
- Upgraded from simple function module to GenServer with state
- Recipient routing: :all (assembly_all, breaking_camp, moadim),
:kohanim (assembly_leaders, war), :operators (war)
- PubSub via BEAM messaging: subscribe/1, unsubscribe/1
Signals delivered as {:chatzotzrot, record} messages
- Zikaron (remembrance — Bamidbar 10:10): signal history with
type filtering and limit. V'hayu lakhem l'zikaron.
- Dead subscriber cleanup via Process.monitor/1
- Added to supervision tree in application.ex
- 30 new tests: patterns, urgency, routing, subscription,
zikaron history, dead process cleanup, format compliance
- All 125 Elixir tests pass, 0 failures
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Torah grounds each change:
1. interpret.pl — coupling_trace field (Vayikra 10:1, 6:6)
Fire is zarah because "asher lo tzivah otam" — the coupling trace
IS the tzivah trace. Records which L1 facts grounded each interpretation.
2. challenge.pl — grounding_type achorai/panim (Shemot 33:23)
"You will see My back, but My face shall not be seen."
Text-backed challenges = achorai. Inferred challenges = panim.
3. resolve.pl — self-grounding detection (eish_zarah_reading §5.3)
Counter-interpretation must bring NEW L1 evidence. Prevents
circular reasoning (Westworld problem).
4. teiku.pl — challenge_sequence in teiku_record
Records diagnostic trail to impasse, not just verdict.
5. avodah_zarah.pl — Form 2: golden calf detection (Shemot 32:4)
Empty coupling trace + non-low confidence = uncoupled output.
Real gold, sincere worship, false god.
6. korban.py — pydantic BaseModel + raw_korban preservation
Construction spec §1.4 fulfilled. Floor between input and output
never severed.
490 tests, 0 failures (195 Prolog, 186 Python, 33 Haskell, 76 Elixir).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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>
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>
1. Chatzotzrot signal mapping corrected to match Architecture §3.12:
assembly_all→tekiah, assembly_leaders→teruah,
breaking_camp→tekiah_teruah, moadim→tekiah_tekiah.
Four of five patterns were swapped. All five now match Bamidbar 10.
2. Manna parse_datetime(nil) bug fixed: missing expires_at now fails
validation instead of silently returning DateTime.utc_now() which
created a race condition where manna appeared expired.
3. Festival detection implemented in cloud.ex: pre-computed Gregorian
dates for Pesach, Shavuot, Rosh Hashanah, Yom Kippur, Sukkot,
Shemini Atzeret (2025-2028). Pipeline now halts on Yom Tov as
Torah requires. Step 15 verification now covers festival rest.
76 tests, 0 failures (68 prior + 8 new).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Wire HaltConditions.check_all into BereishitCycle.erev_voker so the
three cardinal sin monitors (avodah zarah, shfichut damim, gilui arayot)
actually halt the pipeline. Previously dead code, now live.
Add step15_shema_test.exs — Architecture §6.3 (The Shema Test):
1. Te'amim reception — text's own divisions guide havdalah
2. Ketiv/qere preservation — dual readings never collapse
3. Cloud obedience — Shabbat blocks processing
4. Manna fidelity — no provision means wait
5. Context immutability — ShemaContext unchanged at every stage
6. Halt condition integration — pipeline halts on cardinal sin
7. Full pipeline end-to-end — Bereishit 1:1 through to output
68 tests, 0 failures (46 existing + 22 new).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Three connections built and tested:
- Haskell Shoresh Engine via Erlang Port (JSON lines over stdin/stdout)
- Prolog Talmudic Engine via Unix domain socket (JSON over /tmp/shorashim/talmudic.sock)
- Erlang Sanhedrin via native BEAM calls
New: Server.hs (JSON-line server loop), json_bridge.pl + socket_server.pl
(Prolog socket interface), ShoreshEnginePort + TalmudicEngineSocket +
SanhedrinClient (Elixir GenServer wrappers). BereishitCycle now routes
unresolved cases through Talmudic Engine and Sanhedrin. All connections
gracefully degrade — pipeline falls back to L1 data when engines unavailable.
46 Elixir tests, 33 Haskell tests, 57 Prolog tests — 0 failures.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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>
