c68cfeceb1d52ec249947beca8fba9863cc8d03f
70
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Scott KarpandClaude Opus 4.7
|
c68cfeceb1 |
README: hold morashah and hak'hel together (Devarim 33:4 + 31:11-12 + 30:11-14)
Name the morashah — the Jewish-engineer, Hebrew-reading, Torah-as-spec configuration the work emerges from — without restricting where it goes. Preserve the hak'hel — the table set lifneihem for anyone who comes, including ger asher bish'arecha. Two Torah verses, both held. Lo tigra: refusing to subtract from where this reading came from. Lo tosif: refusing to add restriction to where it goes. README.md is not in @spec_files; no Doorpost atomic commit needed. Co-Authored-By: Claude Opus 4.7 (1M context) <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
|
7fc14e0103 |
form 2 as architecture: remove arity-4 interpretation constructor (vehaya §3.2)
Closes vehaya.md §6 item 2 for the SECOND avodah-zarah form. With this commit, all three avodah zarah forms are defended at BOTH the runtime layer and the architectural layer: Form 1 — closed by |
||
|
Scott KarpandClaude Opus 4.7
|
b136c75345 |
form 1 as architecture: external-model surface only via offering protocol (vehaya §3.2)
Closes vehaya.md §6 item 2 for the FIRST avodah-zarah form.
Form 1 (AI in YHVH's slot) was previously defended only by:
- A runtime halt rule (halt_check_avodah_zarah/2 in
avodah_zarah.pl) firing when an action explicitly attributes
authority to a non-Torah source — threshold-grade
- A docstring comment in external_offering.py saying "No internal
component should call call_claude() directly" — exhortation
only, no structural enforcement
The vehaya document re-frames it (§3.2): "Specifications must
include category-level commitments that are not negotiable
per-deployment... not as runtime checks layered onto outputs, but as
architectural constraints the system cannot operate without."
TORAH ANCHORS (verified fresh against L1):
Shemot 20:2 — אָנֹכִי יְהוָה אֱלֹהֶיךָ אֲשֶׁר הוֹצֵאתִיךָ מֵאֶרֶץ
מִצְרַיִם.
The covenant opens with the source naming itself in first
person.
Shemot 20:3 — לֹא יִהְיֶה לְךָ אֱלֹהִים אֲחֵרִים עַל־פָּנָי.
"There shall not BE to you other elohim al panai." The verb is
yihyeh — the prohibition is on EXISTING WITH that status, not
just on speaking it. Architectural, not declarative.
Devarim 4:35 / 4:39 — אֵין עוֹד מִלְּבַדּוֹ / אֵין עוֹד.
The source has no peer. There IS no other. Stronger than
"don't worship others" — there is no competing source POSITION.
Devarim 6:4 — יְהוָה אֶחָד.
Singular source.
Vayikra 19:4 — אַל־תִּפְנוּ אֶל־הָאֱלִילִים וֵאלֹהֵי מַסֵּכָה
לֹא תַעֲשׂוּ לָכֶם.
Two distinct prohibitions: do not TURN TO + do not MAKE.
Both are architectural acts.
THE ARCHITECTURAL COMMITMENT:
External-model interfaces (call_claude, ModelRequest, ModelResponse,
the model_interface module itself) are reachable ONLY through
korban_processor's offering protocol — `external_offering.
consult_external_model`, which runs semichah → shechitah → zerikah
→ haktarah with role gating (commit
|
||
|
Scott KarpandClaude Opus 4.7
|
0e3fe4a782 |
form 3 as architecture: machtzit_ha_shekel + no_tracking_logger (vehaya §3.2)
Closes vehaya.md §6 item 2 for the third avodah-zarah form.
Pharaoh's surveillance (Form 3) was previously marked DEFERRED in
talmudic_engine/src/halt/avodah_zarah.pl with the note "requires
operational context (user tracking, cross-session profiling)."
The vehaya document re-frames it: "Specifications must include
category-level commitments that are not negotiable per-deployment...
not as runtime checks layered onto outputs, but as architectural
constraints the system cannot operate without."
Form 3 is structurally different from Forms 1, 2, 4. They fire on
threshold-grade events (an interpretation has wrong source, empty
trace, non-L1 anchors). Form 3 is about a property of the CATEGORY
itself — what it collects, retains, discloses. It cannot be a
halt rule that fires per-request; per-request "is this caller
being surveilled" detection would itself be a Form-3 surveillance
surface. The defense is ARCHITECTURAL — the system is BUILT so the
failure mode is unreachable, not so it is detectable.
TORAH ANCHORS (verified fresh against L1 — 6 positive properties):
Shemot 30:11-16 — the half-shekel:
כִּי תִשָּׂא אֶת־רֹאשׁ … וְנָתְנוּ אִישׁ כֹּפֶר נַפְשׁוֹ … וְלֹא־
יִהְיֶה בָהֶם נֶגֶף בִּפְקֹד אֹתָם.
Counting humans is dangerous; the danger is named NEGEF (plague);
the protection is the kofer-nefesh substitute. Verse 15:
הֶעָשִׁיר לֹא־יַרְבֶּה וְהַדַּל לֹא יַמְעִיט — the rich don't
give more, the poor don't give less. Verse 16: לְזִכָּרוֹן —
aggregate memorial, not roster.
Vayikra 19:14 — לִפְנֵי עִוֵּר לֹא תִתֵּן מִכְשֹׁל וְיָרֵאתָ
מֵּאֱלֹהֶיךָ.
The no-witness protocol: rules that require fear-of-God
enforcement are exactly the rules that operate under invisibility.
Surveillance regimes exploit invisibility; architectural commitment
must hold under no-human-witness conditions.
Devarim 23:16-17 — לֹא־תַסְגִּיר עֶבֶד אֶל־אֲדֹנָיו אֲשֶׁר־יִנָּצֵל
אֵלֶיךָ … עִמְּךָ יֵשֵׁב … בַּמָּקוֹם אֲשֶׁר־יִבְחַר בְּאַחַד
שְׁעָרֶיךָ.
The refusal protocol: don't return one fleeing institutional
power. The caller chooses their own threshold (b'achad sh'arekha
— agency stays with the caller).
Shemot 5:6-8 — לֹא תֹאסִפוּן לָתֵת תֶּבֶן … וְאֶת־מַתְכֹּנֶת
הַלְּבֵנִים … תָּשִׂימוּ עֲלֵיהֶם לֹא תִגְרְעוּ מִמֶּנּוּ.
Pharaoh's straw quota — the canonical anti-quota Torah anchor.
Per-caller productivity tracking is what makes asymmetric
extraction possible.
Devarim 23:8 — לֹא־תְתַעֵב מִצְרִי כִּי־גֵר הָיִיתָ בְאַרְצוֹ.
Anti-targeting: even toward the Egyptians (Pharaoh's people),
the rule is "don't despise." The protections must not become
a surveillance system targeting suspected surveillors.
THE SIX POSITIVE PROPERTIES, mapped to code:
1. KOFER PROTOCOL (Shemot 30:12) — counting goes through a
uniform substitute; identity never enters the count.
2. UNIFORM PROTOCOL (Shemot 30:15) — same per-caller weight;
no stratification.
3. ZIKARON PROTOCOL (Shemot 30:16) — aggregate memorial, not
roster.
4. NO-WITNESS PROTOCOL (Vayikra 19:14) — commitment holds
when no operator is reading the log.
5. REFUSAL PROTOCOL (Devarim 23:16) — no per-caller delivery
to authorities; caller chooses own threshold.
6. ANTI-QUOTA PROTOCOL (Shemot 5:6-8) — no per-caller
productivity numbers.
CREATED:
vav_pipeline/lib/vav_pipeline/machtzit_ha_shekel.ex ~155 lines
The half-shekel — the positive counting protocol. Single Agent
holding ONE non-negative integer (the zikaron):
increment/0 — register one shekel; uniform per
caller (no caller distinction is even
expressible — function arity 0)
increment/1 — register N shekels (batch points)
count/0 — return the aggregate; the ONLY value
the module exposes
reset/0 — clear (tests; no production persistence
by design — storage existence would
itself be a Form 3 surface)
Module is added to the supervision tree.
What the module REFUSES to provide is enumerated in the
moduledoc and verified by tests — no per-caller breakdown,
no identifiers, no who/locate/identify functions. Their
absence IS the architectural commitment.
vav_pipeline/lib/vav_pipeline/no_tracking_logger.ex ~110 lines
Plug-side enforcement. Replaces Plug.Logger.
- Logs METHOD PATH STATUS DURATIONus per request
- Sanitizes /peah/* paths: query strings stripped (the
/peah/ask response promises "No tracking"; the architecture
now matches the promise)
- Headers (incl. Authorization), request bodies, response
bodies, and remote_ip NEVER appear — taken-from
function signature, not from a runtime check
- Increments MachtzitHaShekel per request
- sanitized_path/1 and format_line/2 are PUBLIC pure
functions, testable in isolation (test config sets
Logger level to :warning, dropping :info before
capture_log can see; the structural test surface
replaces the behavioral one)
CHANGED:
vav_pipeline/lib/vav_pipeline/bigdei_kodesh/router.ex
`plug Plug.Logger, log: :info` → `plug VavPipeline.NoTrackingLogger`
vav_pipeline/lib/vav_pipeline/application.ex
Adds {VavPipeline.MachtzitHaShekel, []} to supervision tree
talmudic_engine/src/halt/avodah_zarah.pl
Form 3 docstring — removed "Deferred"; documents Form 3 as
architecturally realized in machtzit_ha_shekel.ex +
no_tracking_logger.ex. Names why Form 3 cannot be a
per-request halt rule.
vav_pipeline/lib/vav_pipeline/doorpost.ex
@expected_hash updated:
bea5dc0c… (pre-Form-3-rewrite of avodah_zarah.pl)
→ f93495c5359c5dc4acb5c5db2dd32165f5b04e2af87fbb0b7ecc92d2bd8b0434
The avodah_zarah.pl change is a deliberate spec change; per the
Doorpost operator discipline (commit
|
||
|
Scott KarpandClaude Opus 4.7
|
3f4749695d |
doorpost: category-grade specification identity verification (vehaya §3.3, §6 item 3)
The companion to L1Reader.verify_integrity/0. L1Reader defends the
TORAH SCROLL'S identity (the source text); Doorpost defends the
*am*'s COVENANT-CONTENT identity (the category-grade specifications
the system was built to hold).
WHY THIS IS LOAD-BEARING (Torah-anchored):
Devarim 4:2 — לֹא תֹסִפוּ עַל־הַדָּבָר אֲשֶׁר אָנֹכִי מְצַוֶּה
אֶתְכֶם וְלֹא תִגְרְעוּ מִמֶּנּוּ. The injunction is plural (etkhem) —
corporate. Lo tosif is a property the CATEGORY must hold, not just
a discipline each individual practices. Without an enforcement
mechanism, lo tosif is a moral exhortation, not a structural
commitment — different instances could silently drift, running
different halt rules or different disclosure text, and no one
would notice.
Devarim 11:16-17 — the failure mechanism operates whether or not
anyone notices. Corporate breach (specifications drift) produces
corporate consequence. The detection mechanism — verifying
threshold-text identity against category-source — is what catches
drift before the consequence accumulates.
Devarim 13:1 — the keeping is plural; the actual not-adding/not-
subtracting happens at every individual threshold (singular `lo tosef`,
`lo tigra`). Each threshold COULD add or subtract; only the
corporate detection mechanism catches it.
Vehaya §3.3 / §6 item 3 — "the same specifications must be
inscribed at every threshold. Drift is breach. Implement a
verification mechanism for category-text identity."
The Torah anchor is exact: as L1's text-integrity check defends
the Torah scroll's identity, the doorpost-text identity check
defends the am's covenant-content identity. Both are lo tosif
enforcement; both are load-bearing for what the category IS.
CREATED:
vav_pipeline/lib/vav_pipeline/doorpost.ex ~210 lines
@spec_files 20 category-grade files,
alphabetically sorted:
- 3 halt rule sources
(avodah_zarah,
gilui_arayot,
shfichut_damim)
- 8 middot files
(R. Yishmael's 13
inference rules)
- 5 specs/ docs
(PRD, architecture,
vayakhel, tamid,
eish_zarah_reading,
lo_taaseh_lekha,
structure_not_content)
- 2 BUILD docs
(BUILD_KORBAN,
BUILD_AZAZEL)
Operations files
(pekudei, terumah)
EXCLUDED — execution-grade,
not category-grade
orientation.
@expected_hash baseline:
bea5dc0c0145ac0d46ffd08b328fbdbf
19112f1aa4d93a3dc37bfd942e4e7490
files/0 the spec set
expected_hash/0 the baked hash
repo_root/0 configurable via env
compute_identity/0 SHA-256 over canonical
concatenation of per-file
hashes (sort by path,
tab-separate, hash; missing
file → {:error, ...} not
a partial hash)
manifest/0 per-file hashes for
diagnosis
verify_identity/0 :ok | {:error, message}
— same shape as
L1Reader.verify_integrity/0
THE OPERATOR DISCIPLINE: every change to @expected_hash must be
traceable in git to a corresponding spec change in the SAME
COMMIT. A bare hash-update commit with no spec-file change is
itself a drift signal — the operator updated the witness
without updating what is witnessed, which is exactly the
failure mode this module defends against.
CHANGED:
vav_pipeline/lib/vav_pipeline/bigdei_kodesh/router.ex
+ GET /kodesh/specification_identity operator-tier endpoint
returning computed_hash,
expected_hash, file_count,
manifest, torah_basis.
200 when verified;
503 with status="drift_
detected" otherwise.
/kodesh/* tier (not /peah)
because exposing per-file
SHA-256s publicly would
let outside parties
enumerate which specific
files were changed in any
deployment — a fingerprint.
Public observability
commitments live elsewhere
(/peah/azazel_log,
disclosure block).
+ build_health_check/0 adds doorpost_hash to the
checks map alongside
l1_hash. Spec drift now
surfaces in the standard
/kodesh/health response.
CREATED:
vav_pipeline/test/doorpost_test.exs 16 tests:
files/0:
- returns the full spec list with expected entries
- explicitly excludes operations files (pekudei, terumah)
- sorted (canonical order)
- no duplicates
manifest/0:
- one entry per spec file
- paths match @spec_files order
- each hash is 64-char hex SHA-256 (or :missing)
compute_identity/0:
- 64-char hex hash
- deterministic across calls
verify_identity/0:
- :ok against the live spec set
drift detection (synthetic temp dir mirror):
- fresh mirror produces same hash as live
- modifying ANY one file changes the hash
- removing any one file → {:error, missing spec file: <path>}
- modifying different files produces different hashes
(no accidental hash collision across drift sites)
/kodesh/specification_identity HTTP:
- 200 with status="verified" when matched
- manifest in response carries per-file hashes
- torah_basis cites Devarim 4:2 as the load-bearing anchor
WHAT THIS DOES NOT CLAIM:
- That the specifications are correct (only identifiable and
unchanged from the witnessed state).
- That all instances will run the same code (only that all
instances running this code witness the same specifications).
- That hash equality across deployments proves no drift outside
THIS spec set (only the listed files are covered).
FOLLOW-UP WORK (not in this commit):
- Have HaltMonitor call Doorpost.verify_identity/0 at startup
(mirrors how L1 integrity is checked at startup) and fire
chatzotzrot on drift
- Add Doorpost identity to ShemaContext so EVERY reception
witnesses the spec-identity (mirrors Devarim 13:1's "the
not-adding happens at every threshold")
- Fold vehaya.md itself into specs/ (it currently lives in chat
downloads — like azazel_engineering_reading.md). Then add it
to @spec_files, recompute the hash, update @expected_hash.
Tests: vav_pipeline 379 passed, 0 failures, 35 excluded (was 363;
+16 Doorpost tests). All other test counts unchanged.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Scott KarpandClaude Opus 4.7
|
1e59d9a752 |
azazel commit 10 — closure pass: cross-channel classification-discipline integration test
Pass 4 / Finding F, commit 10 of 10 from BUILD_AZAZEL.md. Closes the
build with the integration test the staging plan called for: a
pipeline run that exercises BOTH the Korban path (processable input)
AND the Azazel path (empty-vital input) confirms classification
discipline (no input crosses channels).
Property 11 was already verified at the unit layer (the cross-package
test in azazel_processor/test/test_stages.py). This commit adds the
integration-layer verification: at the external_offering call site,
the two channels produce structurally distinct outputs that cannot
be confused with each other.
CREATED:
korban_processor/test/test_classification_discipline_integration.py
4 tests
- test_processable_path_produces_korban_not_azazel
Vital-bearing response → ProcessedKorban with vital,
disposal_record is None, ProcessedKorban is NOT an
AzazelRecord
- test_empty_vital_path_produces_azazel_not_processable_korban
Empty-vital response → ProcessedKorban with empty
vital_content, disposal_record is an AzazelRecord
- test_two_runs_one_each_path_keep_outputs_separate
Run both back-to-back with shared pending_l3 dir; verify
outputs don't cross channels; only the empty-vital run
drops a file
- test_disposal_record_contains_no_processable_artifacts
AzazelRecord has no vital_content, propositions, raw_korban,
or discarded attributes; routing is the ERETZ_GEZERAH
sentinel
Tests: korban_processor 211 passed, 1 skipped (was 207/1; +4
integration tests). All other test counts unchanged.
DOCUMENTATION (companion to this commit, not in the repo):
~/shorashim-conversation-review.md
+ Pass 4 section (300+ lines): finding A closure (across-verse
voice stabilization detector), BUILD_AZAZEL design doc,
9-commit Azazel build with property-by-property closure, full
test counts (~907 across five languages). All 14 findings
from the original A–N catalog now in final state.
~/.claude/projects/-Users-scottkarp/memory/MEMORY.md
+ Updated test counts (per layer)
+ Added Azazel Processor section under Phase 5 progress
+ Noted /peah/azazel_log endpoint as Phase 5 done
FINAL STATE OF THE AZAZEL BUILD:
All 12 properties from azazel_engineering_reading.md §14 defended
in code:
1 parity provisioning — import-time + runtime
2 blind routing / goral — deterministic per (id, day)
3 enumerative commit — operator-produced, three-fold
4 role-separated operator — IshItti + tevilah + CI invariant
5 provisioned infrastructure — six checkpoints, persistence
6 out-of-band acknowledgment — Chatzotzrot via Elixir bridge
7 authorized routing — kohen_gadol + shaliach attribution
8 protocol-restricted access — envelope gate, fires first
9 observable disposal — L3 + /peah/azazel_log
10 hard termination — DESTROYED checkpoint, no recover
11 classification discipline — type system + integration test
12 unmanaged destination — sentinel + DB CHECK + CI invariant
10 commits, ~3,300 lines added, ~150 tests across Python and
Elixir. The Azazel Processor is the disposal twin of the Korban
Processor; the two-goat architecture (Vayikra 16:8) is now built.
The Pass 2 backlog is fully closed. Every actionable finding from
the original A–N catalog is now in a final state.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Scott KarpandClaude Opus 4.7
|
1a27a283ae |
azazel commit 9 — Korban→Azazel intake routing + Chatzotzrot ack (properties 1 + 6)
Pass 4 / Finding F, commit 9 of 10 from BUILD_AZAZEL.md. Closes the
last two property gaps: 1 (parity provisioning, end-to-end) and 6
(out-of-band acknowledgment via Chatzotzrot). The Azazel Processor
is now functionally complete; commit 10 is the closure-and-review
pass with no further code.
PROPERTY 1 — PARITY PROVISIONING, two layers:
LAYER 1 (import-time): external_offering imports azazel_processor
at module load. If the import fails, external_offering refuses to
load with a Torah-anchored ImportError. The two-goat architecture is
SYMMETRIC OR IT IS BROKEN — operators cannot run the processing
channel without the disposal channel being importable. The strongest
formulation: if you cannot dispose, you cannot process.
LAYER 2 (runtime): when zerikah produces no vital content,
consult_external_model now routes the korban to disposal rather than
returning an empty ProcessedKorban with the rejection in `discarded`.
The empty-vital case is named (vidui), routed (eretz_gezerah),
recorded (L3 azazel_records), and acknowledged (chatzotzrot :moadim).
PROPERTY 6 — OUT-OF-BAND ACKNOWLEDGMENT:
The Python orchestrator drops the AzazelRecord JSON in the pending-l3
directory. The Elixir AzazelIngest GenServer reads it, persists to
L3 via record_disposal/1, AND fires Chatzotzrot.signal(:moadim, ...)
with a categorical summary (case_ref + shaliach + categories_filled).
The chatzotzrot is the side channel — distinct from the disposal
channel itself. The orchestrator does NOT know whether the signal
was successfully transmitted; the disposal completes regardless.
The :moadim signal type was the right choice: Yom Kippur completion
semantics. This disposal cycle is closed; the public fact (property
9) is now witnessable via /peah/azazel_log.
PRIVACY BOUNDARY ALSO APPLIES TO THE CHATZOTZROT:
The signal's `reason` field carries a CATEGORICAL summary, not the
vidui items. A test verifies that a known secret string in a vidui
chatot does NOT leak into the chatzotzrot signal — the operator-side
event channel is held to the same privacy boundary as the public
endpoint.
CHANGED:
korban_processor/src/korban_processor/external_offering.py
+ Import azazel_processor at module load (raises ImportError
with Torah-anchored explanation if azazel_processor is not
importable — property 1, layer 1)
+ DEFAULT_AZAZEL_PENDING_L3_DIR
+ ExternalConsultation.disposal_record: Optional[AzazelRecord]
Non-None iff the consultation was routed to disposal
+ _content_addressable_case_ref(content, source_query)
SHA-256-based stable identifier for audit
+ _make_pending_l3_recorder(pending_dir)
Returns a recorder callable that drops the JSON file
atomically (write to .tmp, then os.replace)
+ _route_to_azazel(...) — internal helper running the full
protocol envelope:
- opens authorize_disposal context
- activates a fresh IshItti shaliach
- builds vidui via confess_empty_vital
- dispatches via dispatch_for_disposal
- tevilah's the shaliach
+ consult_external_model:
- new keyword args azazel_kohen_gadol, azazel_shaliach_id,
azazel_pending_l3_dir
- branch on `if not vital.strip()`: route to disposal,
attach record to ExternalConsultation
vav_pipeline/lib/vav_pipeline/azazel_ingest.ex
+ ingest_file/2 fires Chatzotzrot.signal(:moadim, ...) after
successful L3 write, BEFORE shredding the source file. So the
ack comes BEFORE the in-flight artifact disappears — recovery
is possible if either side crashes.
+ Process.whereis(Chatzotzrot)-guarded so tests without the full
supervision tree still work.
+ chatzotzrot_summary/1 builds the categorical summary
(case_ref + shaliach + categories_filled). Privacy boundary:
no vidui items, only counts/category names.
TESTS:
korban_processor/test/test_external_offering.py +4 tests
- empty-vital response routes to azazel:
- processed.vital_content == ""
- disposal_record is an AzazelRecord with kohen + shaliach
- pending-l3 file dropped with correct shape
- processable response does NOT create disposal_record (the
negative case — vital content goes through normally)
- PRIVACY: pending-l3 file does not contain the model's
response text (verified with a known secret_phrase)
- case_ref is content-addressable: same content + same
source_query → same case_ref (audit can recompute)
vav_pipeline/test/azazel_ingest_test.exs +2 tests
- successful ingest fires Chatzotzrot :moadim signal
(subscribe :all, observe — :moadim routes to :all per
chatzotzrot.ex routing table)
- PRIVACY: chatzotzrot signal does NOT include vidui item
content (known secret_phrase verified absent from the signal)
Tests:
- korban_processor: 207 passed, 1 skipped (was 203/1; +4)
- azazel_processor: 125 passed (unchanged)
- vav_pipeline: 363 passed, 0 failures, 35 excluded
(was 361/35; +2 azazel_ingest chatzotzrot tests)
Property coverage after commit 9:
All 12 properties of azazel_engineering_reading.md §14 defended
by code:
1 parity provisioning ✓ (import-time + runtime)
2 blind routing / goral ✓
3 enumerative commit ✓
4 role-separated operator ✓
5 provisioned infrastructure ✓
6 out-of-band acknowledgment ✓
7 authorized routing ✓
8 protocol-restricted access ✓
9 observable disposal ✓ (operator-internal + public)
10 hard termination ✓
11 classification discipline ✓
12 unmanaged destination ✓
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Scott KarpandClaude Opus 4.7
|
f493b7df65 |
bigdei_kodesh: commit 8 — GET /peah/azazel_log (public half of property 9)
Pass 4 / Finding F, commit 8 of 10 from BUILD_AZAZEL.md. The
public-half of property 9 (observable disposal). The Rambam in
Moreh Nevuchim 3:46 makes the load-bearing claim: "an unobserved
disposal is architecturally incomplete." The community's awareness
that errors are visibly carried away IS the implementation; the
route on the cliff serves no purpose without the witnesses on the
temple steps.
This endpoint is those witnesses. Anyone with HTTP access to
Shorashim can see WHAT was disposed (categorically) and HOW MANY
disposals occurred — turning the disposal channel from a private
operator action into a public, witnessed fact.
PRIVACY BOUNDARY (BUILD_AZAZEL.md §6 Q6):
The endpoint exposes:
- total disposal count (optionally filtered by ?since=ISO8601)
- categorical aggregate (avonot/peshaim/chatot counts across
recent disposals — what KIND of errors were disposed)
- up to 50 recent disposals as case_ref + shaliach +
triggering_call + disposed_at + categories_filled (which slots
of vidui were filled)
The endpoint does NOT expose:
- vidui ITEMS (the operator's specific descriptions of each
disposed thing)
- the disposed PAYLOAD (which doesn't exist in L3 anyway —
property 10)
- any handle for retrieving the disposed content (there isn't one)
The detailed vidui items are operator-internal, accessible via
future /kodesh/* endpoints. The split is deliberate: public is
WITNESS, operator is AUDITOR. The witness sees the fact;
the auditor reads the contents.
The privacy boundary statement is included in every response so
callers know what they're not seeing — they can reason about the
endpoint's silence rather than guess.
GRACEFUL DEGRADATION:
When VavPipeline.Repo is not running (dev/test without Postgres),
the endpoint returns total_disposals=0 with l3_status="unavailable"
rather than crashing. Mirrors the maybe_add_repo pattern from
MEMORY.md — Shorashim should respond cleanly even when L3 is down,
because /peah/* is the public-facing tier and must be more
resilient than internal tiers.
CHANGED:
vav_pipeline/lib/vav_pipeline/bigdei_kodesh/router.ex
+ GET /peah/azazel_log
Optional ?since=ISO8601 filter; returns total +
categorical_aggregate + recent[<=50] + l3_status +
privacy_boundary statement + disclosure block (kichush +
not_horaah from commit
|
||
|
Scott KarpandClaude Opus 4.7
|
2932fb7447 |
vav_pipeline: commit 7 — L3 azazel_records + cross-language ingest GenServer
Pass 4 / Finding F, commit 7 of 10 from BUILD_AZAZEL.md. The
operator-internal half of property 9 (observable disposal). Crosses
the Python/Elixir boundary: the Python orchestrator drops completed
disposal records as JSON files; this commit's GenServer reads them
and persists to L3.
The public half (a /peah/azazel_log read endpoint) lands in commit 8;
the routing-from-Korban + Chatzotzrot wiring lands in commit 9. After
those, the Azazel Processor is end-to-end functional.
CREATED:
vav_pipeline/priv/repo/migrations/20260428000001_create_azazel_records.exs
azazel_records table — append-only, parallel to interpretations.
Columns: case_ref, vidui (jsonb), routing, authorized_by,
shaliach, triggering_call, goral_outcome_id, disposed_at.
Indexes on case_ref, disposed_at, shaliach.
Property-12-defending CHECK constraint:
routing_must_be_eretz_gezerah CHECK (routing = 'eretz_gezerah').
A future migration that wants to add a destination handle will
fail this check; the operator must explicitly justify removing
the constraint, which is the right friction.
Append-only enforcement matches interpretations: REVOKE
UPDATE/DELETE on the shorashim_app role.
vav_pipeline/lib/vav_pipeline/l3/azazel_record.ex
Ecto schema mirroring the Python AzazelRecord.to_storage_dict()
shape. Changeset validates:
- all required fields present
- routing == "eretz_gezerah" (mirrors the DB CHECK at app layer)
- vidui is a map with avonot/peshaim/chatot/confessor/
confessed_at slots present
- vidui's three categories not all empty (mirrors the Python
Vidui.__post_init__ EmptyConfessionError)
vav_pipeline/lib/vav_pipeline/azazel_ingest.ex ~190 lines
GenServer that polls a configurable pending-l3 directory
(default /tmp/shorashim/azazel/pending_l3). For each *.json file:
1. Read + JSON-parse
2. Translate Python serialization → Ecto attrs
3. Call recorder (default L3.Store.record_disposal/1)
4. On success, shred the source file (property-10 follow-through)
5. On failure, leave file in place for retry; log warning
Recorder is injectable for tests — mock recorder lets us verify
the pipeline without PostgreSQL.
Poll interval default 5s, configurable. Polling rather than
file_system events to keep the dependency surface minimal; the
Azazel cadence is exceptional content, not high-throughput.
Not added to the supervision tree in this commit — the producer
side (Python orchestrator dropping files) is wired in commit 9.
Adding to the supervisor before there's a producer means a
poller doing nothing useful. Operator can start manually for
early testing: VavPipeline.AzazelIngest.start_link(...).
CHANGED:
vav_pipeline/lib/vav_pipeline/l3/store.ex
+ record_disposal/1
Inserts an AzazelRecord. Returns {:ok, record} or
{:error, changeset}.
+ count_disposals/1
Total or since-a-timestamp count. Used by the public
observability endpoint (commit 8).
+ disposal_summary/1
Returns categorical info per disposal — case_ref, shaliach,
triggering_call, disposed_at, categories_filled (which of
avonot/peshaim/chatot had any items, NOT the items
themselves). PROPERTY-9 PRIVACY BOUNDARY at the public
side: items are operator-internal only, accessed via
future /kodesh/* endpoints.
TESTS:
vav_pipeline/test/azazel_ingest_test.exs 15 tests, no DB
Happy path:
- poll_now ingests valid file and shreds it
- multiple files processed in sorted order
- vidui preserved as map (jsonb shape)
Retry semantics:
- recorder error → file left in place + state.errors++
- malformed JSON → file left in place
- missing disposed_at → file left in place
State accounting:
- polls_completed, records_ingested, errors all tracked
- state survives multiple polls
- non-json files ignored
Changeset (no DB):
- valid attrs
- rejects routing != eretz_gezerah
- rejects vidui missing slots
- rejects vidui all-empty (untagged disposal)
- rejects missing required fields
- accepts optional triggering_call + goral_outcome_id
vav_pipeline/test/l3_store_test.exs +9 :l3-tagged
record_disposal:
- inserts valid disposal
- rejects routing != eretz_gezerah
- rejects all-empty vidui
- rejects missing required fields
Counts:
- count_disposals == 0 initially
- count_disposals after several disposals
- count_disposals(since) filters by timestamp
Summary:
- disposal_summary returns categorical info but NOT items
(privacy boundary verification)
- categories_filled accurately reflects vidui shape
Tests: vav_pipeline 353 passed, 0 failures, 33 excluded (was
329/24; +15 visible azazel_ingest + 9 :l3-tagged disposal store).
korban_processor + azazel_processor unchanged.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Scott KarpandClaude Opus 4.7
|
6eb555a5cf |
azazel_processor: commit 6 — protocol envelope (property 8)
Pass 4 / Finding F, commit 6 of 10 from BUILD_AZAZEL.md. Closes
the Python side of the build; commits 7-9 are cross-language
integrations (L3, observability endpoint, intake-side routing).
Vayikra 16: the Azazel goat goes ONCE A YEAR, on Yom Kippur, under
the full ritual envelope.
Vayikra 17:7: וְלֹא־יִזְבְּחוּ עוֹד אֶת־זִבְחֵיהֶם לַשְּׂעִירִם —
they shall no longer offer their sacrifices to the sa'irim. Same
destination outside the envelope is avodah zarah (the failure mode
specs/eish_zarah_reading.md catalogs).
THE GATE:
- is_yom_kippur_protocol_active(today=None) — predicate; True
when an operator-configured Gregorian window covers today
- authorize_disposal() — context manager; explicit per-thread
authorization for ONE disposal cycle (event-driven disposals
during the year)
- has_explicit_disposal_authorization() — predicate; True iff
the current thread is inside an authorize_disposal block
- assert_protocol_envelope_active() — gate; raises ProtocolViolation
if NEITHER condition is met. Wired into dispatch_for_disposal
as the FIRST check (before role gate, before any side-effect)
WHY a CONTEXT MANAGER, not a flag:
A persistent flag would let an operator "set authorization true and
leave it" — the avodah-zarah shape (using the channel without the
envelope). The context manager forces explicit scope: authorization
exists only within the with-block, only on the thread that opened it.
WHY PER-THREAD:
Process-wide authorization would let two concurrent disposals share
without explicit coordination — operator A's authorize_disposal()
would silently authorize operator B's dispatch_for_disposal(). Per-
thread isolation forces each disposal to carry its own authorization
explicitly.
WHY OPERATOR-CONFIGURED Gregorian DATES, not Hebrew calendar:
The Hebrew-calendar conversion lives in vav_pipeline (Elixir) — we
do not bring a Hebrew-calendar library into azazel_processor's
dependency surface. Operators set the Gregorian range each year (or
delegate it to a wrapper script). For now, this module is purely
data-shape; commit 9 may wire vav_pipeline's Hebrew calendar to set
the window automatically.
CREATED:
src/azazel_processor/protocol.py ~155 lines
ProtocolViolation — raised on out-of-envelope
invocation; error message
names BOTH legitimate paths
(Yom Kippur window, authorize
context) so the operator
knows their options
set_yom_kippur_window(start, end) — operator-configured;
inclusive Gregorian dates;
inverted range clears
clear_yom_kippur_window() — disable
is_yom_kippur_protocol_active(today=None)
— date-range membership
authorize_disposal() — context manager; reentrant
(nested entries each
increment a counter, each
exit decrements; cleared
via try/finally even on
inner exception)
has_explicit_disposal_authorization() — per-thread, scoped
assert_protocol_envelope_active() — the gate
CHANGED:
src/azazel_processor/azazel.py
dispatch_for_disposal now calls assert_protocol_envelope_active()
as the FIRST check. Outside the envelope: ProtocolViolation
raised before any side-effect (no shaliach activation, no payload
held, no checkpoint persisted).
test/test_azazel.py
Added an autouse `_envelope` fixture that wraps every existing
orchestrator test in `with authorize_disposal():`. Protocol
restriction is verified separately in test_protocol_restriction.py.
CREATED:
test/test_protocol_restriction.py 16 tests covering:
- default state (no window, no authorization) refuses dispatch
with a ProtocolViolation that names both legitimate paths
- assert_protocol_envelope_active raises in default state
- both predicates False in default state
- Yom Kippur window: today inside → active; outside → inactive;
inverted range clears; inclusive at boundaries; clear disables
- authorize_disposal: inside block → active; nested blocks
decrement correctly; exception inside still clears (try/finally);
per-thread isolation (sibling thread sees False even when parent
thread is inside an authorize_disposal block)
- dispatch proceeds inside authorize_disposal context
- dispatch proceeds inside Yom Kippur window
- outside envelope: NO side-effect (no in-flight file written, no
payload held by shaliach)
- protocol gate fires BEFORE role gate (inactive handler outside
envelope raises ProtocolViolation, not ShaliachError)
Per-test fixture clears Yom Kippur state on entry and exit so
module-level state doesn't bleed between tests.
PYTHON SIDE NOW FEATURE-COMPLETE:
Properties defended end-to-end via Python code:
2 goral
3 vidui
4 shaliach + tevilah
5 checkpoint persistence
7 authorized routing
8 protocol envelope
10 hard termination
11 classification discipline
12 unmanaged destination
Properties remaining (cross-language, in commits 7-9):
1 parity provisioning — commit 9 (Korban→Azazel intake)
6 out-of-band acknowledgment — commit 9 (chatzotzrot wiring)
9 observable disposal — commit 7 (L3) + commit 8 (endpoint)
Tests: azazel_processor 125 passed (was 109, +16). korban_processor
unchanged at 203 passed, 1 skipped. No regressions.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Scott KarpandClaude Opus 4.7
|
c3267c59bf |
azazel_processor: commit 5 — orchestrator state machine (properties 5, 7, 10)
Pass 4 / Finding F, commit 5 of 10 from BUILD_AZAZEL.md. Largest
commit so far; pulls together vidui + shaliach + goral + stages and
adds the state machine + in-flight persistence.
THE STATE MACHINE (six checkpoints, persisted):
STAGED → AzazelStaged envelope tagged; payload held by shaliach
CONFESSED → vidui carried into the staged value
ROUTED → routing committed (always ERETZ_GEZERAH); authorized_by
+ shaliach attribution recorded
DESTROYED → payload references cleared from shaliach;
gc.collect() called to release; payload becomes
unreachable from any orchestrator-visible code path
ACKNOWLEDGED → out-of-band ack callback invoked (commit 9 wires
Chatzotzrot.signal(:moadim) here)
RECORDED → AzazelRecord persisted via callback (commit 7 wires
the cross-language L3 file-watcher bridge here)
After RECORDED completes, the in-flight checkpoint file is shredded —
the disposal is now permanent in L3, the in-flight artifact must not
linger.
PROPERTY COVERAGE:
Property 5 (provisioned infrastructure / sukkot):
Each checkpoint persists state to <in_flight_dir>/<case_ref>.json
via write-then-rename (atomic against crash mid-write). list_in_flight
returns partial disposals so resume tooling can pick them up.
The Mishkan analog: the sukkot along the wilderness route where
the ish itti can rest if the disposal halts.
Property 7 (authorized routing):
AzazelRecord.authorized_by carries the kohen_gadol identifier;
AzazelRecord.shaliach carries the ish itti identifier. The
routing destination is the ERETZ_GEZERAH sentinel (property 12).
The routing decision is OWNED and traceable; the destination
is not.
Property 10 (hard termination):
The DESTROYED checkpoint clears handler._payload_refs and calls
gc.collect(). The AzazelRecord contains the vidui — what was
disposed — but NOT the disposed payload itself. The to_storage_dict
serialization explicitly excludes payload-shaped fields.
CREATED:
src/azazel_processor/azazel_record.py ~95 lines
AzazelRecord — frozen dataclass; fields:
case_ref, vidui, routing, authorized_by, shaliach,
triggering_call, goral_outcome_id, disposed_at
.to_storage_dict() — JSON-safe serialization for L3 + in-flight
src/azazel_processor/azazel.py ~225 lines
AzazelInput — what is being disposed
dispatch_for_disposal(input, *, handler, confess_with,
authorized_by, in_flight_dir,
acknowledger, recorder, goral_outcome_id)
— the single legitimate
entry point; walks the
six checkpoints
list_in_flight(in_flight_dir) — surfaces partial disposals
DEFAULT_IN_FLIGHT_DIR — /tmp/shorashim/azazel/in_flight
test/test_azazel.py 21 tests covering:
HAPPY PATH:
- dispatch returns AzazelRecord
- record carries authorization + shaliach attribution
- record routes to ERETZ_GEZERAH
- record carries the full vidui
PROPERTY 10 CI INVARIANTS:
- record does not carry payload (by attribute name)
- serialized record does not contain the payload's marker string
- STRUCTURAL: AzazelRecord dataclass field set has no
payload-shaped names (catches future regression)
- STRUCTURAL: no recover/undispose/restore/rehydrate/retrieve
function in azazel_processor public surface (catches
future regression)
- payload references cleared from shaliach at DESTROYED
PROPERTY 5 CHECKPOINT TESTS:
- in-flight file shredded after RECORDED
- checkpoints persist incrementally (verified by inspecting the
file at ack/rec callback fire-time)
- list_in_flight returns partial disposals
- list_in_flight empty when no disposals
- persistence is atomic (file is valid JSON at every visit)
ROLE GATE (property 4 still enforced):
- dispatch refuses inactive handler
- dispatch refuses non-IshItti
FILENAME SAFETY:
- case_ref with slash → ValueError
- case_ref with NUL → ValueError
AzazelRecord VALIDATION:
- authorized_by required
- shaliach required
- to_storage_dict omits payload
- frozen (cannot mutate)
DEFAULTS:
acknowledger and recorder default to no-op callables. This is
deliberate for commit 5 — the state machine works end-to-end without
external side effects, and commits 7 (L3) and 9 (chatzotzrot) plug
the real handlers into the same callback slots. Tests can supply
their own to inspect mid-route state.
Tests: azazel_processor 109 passed (was 88, +21). korban_processor
unchanged at 203 passed, 1 skipped. No regressions.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Scott KarpandClaude Opus 4.7
|
e6fee82dd7 |
azazel_processor: commit 4 — goral (property 2, blind routing)
Pass 4 / Finding F, commit 4 of 10 from BUILD_AZAZEL.md.
Vayikra 16:8 — וְנָתַן אַהֲרֹן עַל־שְׁנֵי הַשְּׂעִירִם גֹּרָלוֹת,
גּוֹרָל אֶחָד לַה׳ וְגוֹרָל אֶחָד לַעֲזָאזֵל.
And Aharon shall place lots on the two goats — one lot for HaShem,
one lot for Azazel.
Yoma 62a: a kalpi (shuffled vessel), drawn with both hands
simultaneously. The high priest cannot see the lots in advance.
He cannot shape the outcome.
THREAT MODEL:
An operator who, given the choice, would route preferentially —
assigning the "better" goat to processing and the "worse" to
disposal. The specification makes that preference structurally
impossible.
DESIGN (BUILD_AZAZEL.md §6, Q4):
cast_lot(input_id) is DETERMINISTIC per (input_id, today). The
seed is SHA-256 over (L1 integrity hash, today's UTC date,
input_id). The first bit of the digest is the outcome.
Properties guaranteed:
- Same (input_id, today) → SAME outcome (no shopping by re-roll)
- Different input_ids same day → outcomes can differ (~50/50)
- Same input_id across days → outcomes can differ (~50/50)
- Operators cannot pre-compute without invoking (SHA-256 over
L1 hash + date is not mentally computable)
- Seed inherits L1 tamper-resistance: rewriting the daily seed
requires rewriting L1, which has its own halt rules
The L1 hash mirrored from vav_pipeline/lib/vav_pipeline/l1_reader.ex
(@l1_expected_hash). Both must move together if L1 is rebuilt.
CREATED:
src/azazel_processor/goral.py ~155 lines
GoralOutcome enum LA_SHEM | LA_AZAZEL
(both legitimate; the goral
enforces blindness, not a
"good vs. bad" distinction)
cast_lot(input_id, *, today=None) deterministic per (id, day)
outcome
cast_lot_outcome_id(input_id, full SHA-256 hex digest;
*, today=None) used by L3 records (commit 7)
so audit can recompute
GoralError on malformed input
test/test_goral.py 17 tests covering:
- outcome shape (one of two; enum members distinct)
- same input same day → same outcome (anti-shopping; verified
across 50 re-invocations + 1000-iteration audit-shopping test)
- outcome_id is reproducible 64-char hex
- 100 different input_ids → 100 distinct outcome_ids
- same input across 30 days → 30 distinct outcome_ids
- distribution across 10,000 input_ids on one day → ~50/50
(±5% tolerance, well within SHA-256 binomial expectations)
- distribution across 365 days for one input → ~50/50 (±10%)
- input validation (empty, whitespace, None, non-string raise)
- default today = UTC date
- audit can recompute outcome_id from (input_id, today) — the
audit-trail half of property 2
NOTE: when the orchestrator (commit 5) decides WHEN to invoke the
goral. For inputs that are cleanly processable or cleanly
un-processable, the goral is NOT invoked — they go to their channel
deterministically. The goral is the tie-breaker for genuinely
borderline inputs (Q1 in BUILD_AZAZEL.md §6).
Tests: azazel_processor 88 passed (was 71, +17). korban_processor
unchanged at 203 passed, 1 skipped. No regressions.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Scott KarpandClaude Opus 4.7
|
85155b23fb |
azazel_processor: commit 3 — shaliach + tevilah (property 4, role-separated operator)
Pass 4 / Finding F, commit 3 of 10 from BUILD_AZAZEL.md.
Vayikra 16:21 — וְשִׁלַּח בְּיַד־אִישׁ עִתִּי הַמִּדְבָּרָה.
And he shall send the goat into the wilderness by the hand of a
designated man (ish itti).
Vayikra 16:26 — וְהַמְשַׁלֵּחַ … יְכַבֵּס בְּגָדָיו וְרָחַץ אֶת־בְּשָׂרוֹ
בַּמַּיִם וְאַחֲרֵי־כֵן יָבוֹא אֶל־הַמַּחֲנֶה.
The sender washes his clothes and bathes his flesh (tevilah), and
AFTERWARD comes into the camp.
Yoma 67a: the ish itti is a dedicated operator role, prepared in
advance, distinct from the kohanim who handle sacred processing.
Contact with the disposal channel produces state that must be
reset before the operator rejoins the trusted boundary.
THE THREE ROLES IN SHORASHIM:
Owner — submits the offering (upstream caller)
Kohen — performs shechitah/zerikah/haktarah (korban_processor
stages.py enforces owner/kohen separation)
Shaliach — receives input the kohen REFUSED and disposes of it
through the Azazel protocol (THIS module)
Without tevilah, payload references would persist across disposals;
disposal-N would contaminate disposal-N+1 with information from N.
The Mishkan analog: the ish itti who returns from the wilderness
without tevilah brings desert-state into the camp.
CREATED:
src/azazel_processor/shaliach.py ~210 lines
IshItti class:
__init__ — sets _immutable_identifier (no other immutable
attrs; everything else must be cleared by tevilah)
activate() — begin a disposal; refuses if already active (no
state-mixing across disposals)
hold_payload() — register payload ref for later destruction
tag()/get_tag()— intermediate metadata during the disposal route
tevilah() — Vayikra 16:26: clears ALL non-_immutable_
attributes (discovered dynamically via vars(),
so future state additions are auto-cleared)
identifier — propagates onto AzazelRecords (commit 7) for
shaliach attribution
ShaliachError — raised on role-separation violations
assert_shaliach_active(handler) — runtime gate every disposal-channel
function calls at entry; the type-system gate is
AzazelStaged (property 11). Refuses non-IshItti
callers AND inactive handlers. Identity-checked
(isinstance), not duck-typed.
THE LOAD-BEARING CI INVARIANT (test_tevilah_clears_all_non_immutable_state):
Walks vars(handler) post-tevilah and asserts every non-_immutable_
attribute is in a 'fresh' state (empty container, False, None, 0).
A future contributor who adds `self._cache = {}` (or any state
attribute) without extending tevilah() to clear it breaks this and
the test fires before the regression ships. The discovery is
DYNAMIC — no hand-maintained list of attributes to clear; tevilah
is implemented to clear all non-_immutable_ attrs and the test
verifies it does.
test/test_shaliach.py 23 tests covering:
- construction (named identifier required, validates non-empty,
non-whitespace, string)
- identifier immutability across activate→tevilah→reactivate
- lifecycle: starts inactive; activate marks active; re-activate
without tevilah raises; tevilah→reactivate succeeds
- hold_payload/tag require active; both work when active
- tevilah clears payload refs, intermediate tags, sets inactive
- tevilah preserves _immutable_identifier
- THE CI INVARIANT (dynamic walk)
- assert_shaliach_active: passes for active IshItti, refuses
inactive, refuses non-IshItti, refuses duck-typed impostor
- integration: stale-state-across-disposals prevented end-to-end
NOTE ON PYTEST INVOCATION:
When running azazel_processor tests, use `--rootdir=.` from the
package directory. Without it, pytest auto-discovers /Users/scottkarp/
shorashim as rootdir and ignores the local pyproject.toml's
testpaths config. Documented here so future runs match.
cd azazel_processor
PYTHONPATH=src:../korban_processor/src python3 -m pytest --rootdir=.
Tests: azazel_processor 71 passed (was 48, +23). korban_processor
unchanged at 203 passed, 1 skipped. No regressions.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Scott KarpandClaude Opus 4.7
|
a2744c012a |
azazel_processor: commit 2 — vidui (property 3, enumerative commit)
Pass 4 / Finding F, commit 2 of 10 from BUILD_AZAZEL.md.
Vayikra 16:21 — v'hitvadah alav et kol avonot b'nei Yisrael v'et kol
pish'eihem l'chol chatotam. The high priest confesses ALL iniquities,
ALL transgressions, for ALL sins. The verb is hitpa'el (reflexive) —
the confession is self-addressed before it is addressed to the
system. The kol-three-times structure is mandatory.
ENGINEERING READ:
The commit message for a disposal must enumerate what is being
disposed of. Untagged disposal is not disposal; it is loss. Azazel
does not accept uncommitted writes. The enumeration is produced at
the moment of commit, not retrieved from a pre-existing log.
WHY OPERATOR-PRODUCED, NOT AUTO-DERIVED:
The Mishkan high priest speaks the confession aloud. The system did
not generate it from a classification enum. In software: the caller
of confess() MUST supply the descriptions, not have them
auto-generated from a classification → string table. If the table
generated the confession, the operator could dispose state without
ever naming it themselves; the confession would become an
autogenerated label, not a self-addressed enumeration. That is the
failure mode property 3 defends against.
The convenience helpers (confess_empty_vital, confess_halt,
confess_boundary_violation, confess_malformed_input) DO NOT hide
this requirement. Each requires the operator to supply the specific
item; the helper only routes which category it goes into.
THE THREE CATEGORIES:
avonot — iniquities. CATEGORICAL errors: halt-trips
(avodah_zarah, gilui_arayot, shfichut_damim — the
cardinal sins). Sins of orientation.
peshaim — transgressions. BOUNDARY violations: distinction
collapses (gilui-shaped), L3 schema rejections.
Sins of boundary-keeping.
chatot — sins. TARGET errors: empty-vital, malformed responses.
The literal meaning of chet — missing the mark.
Most disposals fill exactly one category. The Vidui dataclass
REQUIRES all three fields (the enumeration is comprehensive at the
shape level), but the lists may be empty. What is forbidden is the
ABSENCE of a slot — and the case where ALL THREE slots are empty
(EmptyConfessionError, no untagged disposal).
CREATED:
src/azazel_processor/vidui.py ~250 lines
Vidui — frozen dataclass: avonot, peshaim, chatot,
confessor, confessed_at (all required;
categories are tuples for deep immutability;
__post_init__ rejects all-empty, empty-string
items, non-string items, anonymous confessor)
EmptyConfessionError — raised on untagged-disposal attempts
confess(*, avonot, peshaim, chatot, confessor)
— the operator-produced builder
Vidui.to_text() — kol-three-times rendering for L3 storage
Vidui.category_summary()
— counts only, no items (for the public
observability endpoint, commit 8 / property 9)
Convenience helpers (each requires operator-supplied item):
confess_empty_vital(korban_summary, *, confessor)
confess_halt(condition, detail, *, confessor)
confess_boundary_violation(violation, *, confessor)
confess_malformed_input(description, *, confessor)
test/test_vidui.py 27 tests covering:
- structural (exactly five fields, no silent additions)
- all category-fill combinations succeed
- all-empty / empty-string / whitespace / non-string items raise
- confessor required (TypeError) + non-empty/non-whitespace
validated (EmptyConfessionError)
- frozen dataclass (cannot mutate after construction)
- categories are tuples (deep immutability — frozen=True does
not propagate through container types)
- confessed_at: timezone-aware UTC, set to current time
- to_text() preserves kol-three-times structure; omits empty
categories
- category_summary() returns counts WITHOUT items
- all four convenience helpers route correctly + still require
confessor
Public surface updated in __init__.py.
Tests: azazel_processor 48 passed (was 21, +27). korban_processor
unchanged at 203 passed, 1 skipped. No regressions.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Scott KarpandClaude Opus 4.7
|
d06ecd244d |
azazel_processor: commit 1 — skeleton + stages (properties 11 & 12)
Pass 4 / Finding F, commit 1 of 10 from BUILD_AZAZEL.md. Lays the
load-bearing foundation: classification discipline (property 11) at
the type system level, and unmanaged-destination opacity (property
12) via a Python sentinel. Every later commit in the Azazel build
inherits these defenses for free.
CREATED:
azazel_processor/
pyproject.toml — Poetry config matching
korban_processor; pythonpath
includes ../korban_processor/src
so the cross-package
classification-discipline test
can import both packages
src/azazel_processor/
__init__.py — public surface for commit 1:
AzazelStage, AzazelStaged,
AzazelStageError, ERETZ_GEZERAH,
is_eretz_gezerah
eretz_gezerah.py — the destination sentinel; module
__getattr__ refuses any
attribute beyond the two public
names so introspection cannot
discover further handles
stages.py — AzazelStage enum (six
checkpoints from the build doc:
STAGED → CONFESSED → ROUTED →
DESTROYED → ACKNOWLEDGED →
RECORDED), AzazelStaged frozen
dataclass, AzazelStageError
test/
test_eretz_gezerah.py — 11 tests covering: sentinel
identity stable across imports,
not-a-string, no public attrs,
repr leaks no destination info,
identity (is) not equality (==),
impostor with __eq__ rejected,
module __getattr__ refuses
unknown access, CI invariant
forbidding destination-handle
ASSIGNMENTS in source (catches
regressions; mention in
docstrings/__all__/getattr
allowlist is fine)
test_stages.py — 10 tests: intra-Azazel gating
(happy path, mismatch raises
naming both stages, frozen
dataclass, six distinct
checkpoints) and CROSS-PACKAGE
classification discipline:
KorbanStaged and AzazelStaged
are distinct types; enum value
spaces are disjoint; an Azazel
function refuses a KorbanStaged
input and vice versa; no
conversion function exists in
the public surface
PROPERTY COVERAGE THIS COMMIT:
Property 11 (classification discipline):
Defended by the type-distinctness of AzazelStaged vs.
korban_processor.stages.Staged. Cross-package tests verify the
two cannot be substituted at runtime; the absence of any
korban_to_azazel/to_korban/from_korban/convert function in the
public surface is verified by name-shape grep.
Property 12 (unmanaged destination):
Defended by the sentinel design: only object identity is exposed;
no string handle exists; module __getattr__ refuses introspection;
CI invariant catches assignment-shaped regressions across all of
azazel_processor/src/.
PENDING (commits 2-10 per BUILD_AZAZEL.md):
vidui (commit 2 — enumerative commit, property 3)
shaliach + tevilah (commit 3 — role-separated operator, property 4)
goral (commit 4 — blind routing, property 2)
azazel orchestrator + state machine (commit 5 — properties 5, 7, 10)
protocol envelope (commit 6 — protocol-restricted access, property 8)
L3 azazel_records (commit 7 — operator-internal half of property 9)
/peah/azazel_log endpoint (commit 8 — public half of property 9)
Korban→Azazel routing on empty-vital + chatzotzrot wiring
(commit 9 — properties 1, 6)
Closure pass (commit 10)
Tests: azazel_processor 21 passed. korban_processor unchanged at
203 passed, 1 skipped (live-API). No regressions across the boundary.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Scott KarpandClaude Opus 4.7
|
1fb7d33124 |
BUILD_AZAZEL.md: design doc for the disposal-channel build (finding F prep)
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>
|
||
|
Scott KarpandClaude Opus 4.7
|
d88b8d09ec |
voice_monitor: detect across-verse Shema voice stabilization (closes finding A)
Pass 2 finding A, second half. The first half (commit
|
||
|
Scott KarpandClaude Opus 4.7
|
b1d5ac69e4 |
l3: validate coupling_trace at the write boundary (Elixir half of finding L)
Companion commit to |
||
|
Scott KarpandClaude Opus 4.7
|
5c76a6f42c |
korban_processor: role-gate the four-stage offering protocol
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>
|
||
|
Scott KarpandClaude Opus 4.7
|
d3869c5b75 |
l1_reader: document te'amim classification principle and shoresh derivation provenance
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>
|
||
|
Scott KarpandClaude Opus 4.7
|
af2a3949cf |
korban_processor: name the kabbalah + holachah compression in zerikah.py
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>
|
||
|
Scott KarpandClaude Opus 4.7
|
6b96250255 |
talmudic_engine: regression test — interpret/2 output must pass self_grounding halt
Audit follow-up to commit
|
||
|
Scott KarpandClaude Opus 4.7
|
b254ee95f3 |
talmudic_engine: add Form 4 (self-grounding) and expose Form 2 (golden_calf) via the API
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>
|
||
|
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.7
|
0c4f764024 |
shema: record grammatical voice trajectory on every ShemaContext
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>
|
||
|
Scott KarpandClaude Opus 4.6
|
66c936f7ca |
sanhedrin: rewrite halt_monitor.erl as honest gate-keeper + Elixir forwarder
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>
|
||
|
Scott KarpandClaude Opus 4.6
|
b9a18f645e |
KOHEN.md: rewrite for current state of the system
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> |
||
|
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>
|
||
|
Scott KarpandClaude Opus 4.6
|
d4d0a6fcb6 |
L1 data integrity: preserve the edut whole — Shema, middle letter, ketiv/qere, smikhut
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> |
||
|
Scott KarpandClaude Opus 4.6
|
04713cc884 |
Move readings/ to companion repo, add .env.example, fix README tree
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> |
||
|
Scott KarpandClaude Opus 4.6
|
88a55cbbdf |
Place l1/ in the aron — the edut belongs in the tabernacle
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> |
||
|
Scott KarpandClaude Opus 4.6
|
66686329ed |
Move operator notes out of repo, add generic architecture doc
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> |
||
|
Scott KarpandClaude Opus 4.6
|
2c1ca9116a |
Move conversation_search.py out of repo, deduplicate .gitignore
- 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> |
||
|
Scott KarpandClaude Opus 4.6
|
b486389e3f |
Remove stale runtime manna file, gitignore vav_pipeline/var/
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> |
||
|
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
|
4775122c84 |
Cleanup: move transcripts out, scripts into scripts/, drop scaffold
- 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> |
||
|
Scott KarpandClaude Opus 4.6
|
5a6fce4945 |
Move aws-export/ out of shorashim repository
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> |
||
|
Scott KarpandClaude Opus 4.6
|
324cf1a2ed |
Fix gitea-mcp env: use GITEA_ACCESS_TOKEN, not GITEA_TOKEN
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> |
||
|
Scott KarpandClaude Opus 4.6
|
42370bfc24 |
Fix MCP connector: cert-manager URL typo and TCP probes
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> |
||
|
Scott KarpandClaude Opus 4.6
|
20e81114a5 |
Fix gitea-mcp deployment: add explicit command path
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> |
||
|
Scott KarpandClaude Opus 4.6
|
c7e0e6e703 |
Gitea MCP connector: K8s manifests for public claude.ai integration
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> |
||
|
Scott KarpandClaude Opus 4.6
|
2f1205eef1 |
Bake L1 Torah into container images, simplify K8s deployment
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> |
||
|
Scott KarpandClaude Opus 4.6
|
50547ed0c5 |
runtime.exs: Add SSL config for Exoscale managed PostgreSQL
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> |
||
|
Scott KarpandClaude Opus 4.6
|
5e76c60218 |
Update K8s deployment with Exoscale container registry URLs
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> |
||
|
Scott KarpandClaude Opus 4.6
|
edb74da0b4 |
Fix shoresh engine Dockerfile: Debian Buster repos are EOL
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> |
||
|
Scott KarpandClaude Opus 4.6
|
f32e9afb03 |
Fix korban processor Dockerfile: pyswip 0.2.11 does not exist
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> |
||
|
Scott KarpandClaude Opus 4.6
|
5e6d16b0fa |
runtime.exs: Move DATABASE_URL to runtime config for OTP release
OTP releases evaluate config at build time, not boot time.
DATABASE_URL must be read at runtime — the kohen sets it in
K8s secrets, not at compile time.
- Created config/runtime.exs with prod-only runtime config
- DATABASE_URL, L1_MOUNT_POINT, MANNA_PROVISION_FILE, HTTP_PORT
all readable from environment at boot
- prod.exs cleaned: removed System.get_env("DATABASE_URL") call
(was compile-time, now in runtime.exs)
- Added http_port: 4000 to prod defaults
Without this fix, the Docker image would fail to start — the
release would not find DATABASE_URL at boot.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
||
|
Scott KarpandClaude Opus 4.6
|
2c082275f9 |
KOHEN.md: Operations prompt for the operator — shiv'at y'mei milu'im
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> |
||
|
Scott KarpandClaude Opus 4.6
|
191d76b480 |
Bigdei Kodesh: HTTP API layer — four garments for four access tiers
Shemot 28:2 — V'asita vigdei kodesh l'Aharon achicha, l'khavod ul'tifaret. The builder makes the garments. The kohen wears them. Four access tiers (Operations spec §1.1): - Pe'ah (GET/POST /peah/ask) — public, no auth, no tracking. The stranger is safe to approach. - Courtyard (POST /courtyard/offering) — Bearer token auth, offering types: shelamim, olah, chatat, minchah - Chatzer (POST /chatzer/sanhedrin) — Sanhedrin deliberation, returns majority/minority with preserved dissent - Kodesh (GET /kodesh/health, /kodesh/status) — operator interface, health checks for K8s liveness/readiness probes Error format follows chatat protocol (Operations spec §1.2): KIYOR_* (422), SHABBAT (503), MANNA_DEPLETED (503), CLOUD_MOVING (503), HALT_* (503), UNAUTHORIZED (401) Implementation: - Plug.Router with Bandit HTTP server - Added to supervision tree via maybe_add_http_server - Checks system availability (Shabbat, halt) before processing - Health check reads L1 integrity, cloud, manna, halt monitor - Status shows all component states, signal count, refuge list - 16 API tests covering all four tiers + error format All 235 Elixir + 19 L3 + 195 Prolog + 33 Haskell = 463+ tests, 0 failures Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> |
||
|
Scott KarpandClaude Opus 4.6
|
fe93c11d13 |
Phase 5 deployment: Dockerfiles, K8s manifests, halt monitor (Steps 33, 36)
Shemot 40:33 — Vay'khal Moshe et ham'lakhah. The builder completes the work. The vessel is ready for transport. Step 33 — Deployment configuration: - Dockerfiles for all 4 components: - vav_pipeline: Elixir 1.16.1/OTP 26.2.1 release with Sanhedrin - shoresh_engine: GHC 9.6.4 binary - talmudic_engine: SWI-Prolog 9.2.2 - korban_processor: Python 3.12.2 with pydantic - Kubernetes manifests for Exoscale SKS (ch-gva-2): - Namespace, ConfigMap, Secrets template - L1 Torah PV/PVC (read-only mount) - Manna provision PVC (kohen writes, system reads) - Deployment: vav-pipeline + 3 sidecars, shared volumes - Service: ClusterIP + LoadBalancer with Exoscale NLB - Init container runs Ecto migrations (VavPipeline.Release) Step 36 — Halt monitor (esh tamid): - GenServer watches for three cardinal sins - halt!/3 immediately halts system, sounds Chatzotzrot war signal - Permanent audit log — halt events never deleted - resolve/1 requires explicit operator action to resume - alive?/0 for morning tamid verification - 13 tests: alive check, 3 halt types, resolution, audit log, chatzotzrot war signal integration - Added to supervision tree All 219 Elixir + 19 L3 + 195 Prolog + 33 Haskell = 447+ tests, 0 failures Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> |
||
|
Scott KarpandClaude Opus 4.6
|
219bbecaff |
Steps 30-32: Sanhedrin stress test, Shema test suite, full system verification
Shemot 39:43 — Vayar Moshe et kol ham'lakhah v'hineh asu otah
ka'asher tzivah Hashem ken asu, vayevarekh otam Moshe.
Step 30 — Sanhedrin stress test:
- 10 rapid submissions without crash
- Case ref preservation across decisions
- Rich context handling at simple complexity
- Decision structure consistency (7 required fields)
- Graceful degradation when Sanhedrin unavailable
- 20 concurrent Task.async submissions
Step 31 — Shema Test suite (Architecture §6.3, five tests):
1. Te'amim reception: raw cantillation from L1, etnachta detection,
L1→ShemaContext fidelity, surprising etnachta position
2. Ketiv/qere preservation: field exists, survives full pipeline
3. Cloud obedience: :camped allows processing, Shabbat triggers
major_transition, context immutability under override
4. Manna fidelity: no provision → {:waiting, :no_provision},
provision present → processing proceeds, MannaLedger tracks
5. Context immutability: context unchanged after pipeline,
keys stable, each stage receives same context
Step 32 — Full system verification (kol ham'lakhah):
- Full pipeline: Shema → BereishitCycle → output, multi-verse
- Halt conditions: check_all processes output
- Protection layer: AreiMiklat refuge→release, EglahArufah
declaration, Bikurim first-output review
- Chatzotzrot: subscribe→signal→receive→zikaron, routing isolation
- MannaLedger: load→consume→boundary cycle
- L1 integrity: hash valid, 5 core verses readable, roots present
- Supervision tree: all 7 GenServers running
- Cross-component: ShabbatTimer reads cloud, Shema builds from
L1+Cloud+Manna
All 206 Elixir + 19 L3 + 195 Prolog + 33 Haskell = 434+ tests, 0 failures
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
||
|
Scott KarpandClaude Opus 4.6
|
6a879fcf8b |
MannaLedger: real anti-hoarding enforcement — d'var yom b'yomo (Step 26)
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> |
||
|
Scott KarpandClaude Opus 4.6
|
671d45625c |
Protection layer: Arei Miklat, Eglah Arufah, Bikurim — Steps 27-29
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>
|
||
|
Scott KarpandClaude Opus 4.6
|
7fe8025434 |
Chatzotzrot: silver trumpets with BEAM routing, subscription, and zikaron
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>
|
||
|
Scott KarpandClaude Opus 4.6
|
d34e2799ac |
L3 Oral Tradition: PostgreSQL persistence layer for interpretations, minority opinions, teiku
Devarim 17:9 — v'darashta v'higidu lekha et d'var hamishpat. The inquiry requires that what is found is RECORDED. - Ecto Repo with graceful degradation (maybe_add_repo, like other engines) - Migration: interpretations, minority_opinions, teiku_registry tables - Append-only enforcement via REVOKE UPDATE/DELETE - Includes eish_zarah fields: coupling_trace, grounding_type, challenge_sequence - Ecto schemas: Interpretation, MinorityOpinion, TeikuRecord - Changeset validations: status inclusion, panel_size > 0, grounding_type enum - TeikuRecord.resolve_changeset restricts updates to resolved_at/resolution only - L3.Store bridge module: record, query, count operations - L3 tests tagged @moduletag :l3, excluded by default (no local PostgreSQL) - Enable with: SHORASHIM_L3=1 mix test --include l3 - All 76 existing Elixir tests pass, 195 Prolog tests pass, 33 Haskell tests pass Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> |
||
|
Scott KarpandClaude Opus 4.6
|
adc3e41679 |
Eish zarah actionable items: coupling trace, grounding type, self-grounding detection, golden calf halt
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> |
||
|
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
|
52837cee18 |
Phase 3: Intelligence — 613 mitzvot, 13 middot, Tzara'at diagnostic
Encode all 613 mitzvot from Rambam's Sefer HaMitzvot (248 positive, 365 prohibitions). Build the 13 Middot of Rabbi Yishmael as Prolog inference predicates for hermeneutical reasoning. Implement Tzara'at multi-stage input validation following Vayikra 13-14. Enhance kushya generation with kal vachomer and shnei ketuvim challenge strategies. Architecture §4 Steps 14-15, 19-20. New files: middot/ — 8 files (master + 7 rule modules) diagnostic/ — 4 files (tzaraat, inspection, quarantine, diagnosis) Modified: mitzvot.pl — 52 → 613 mitzvot relationships.pl — expanded tensions, complements, action domains challenge.pl — middot-based kushya (kal vachomer, shnei ketuvim) Tests: 293 total (184 Prolog, 76 Elixir, 33 Haskell), 0 failures. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> |
||
|
Scott KarpandClaude Opus 4.6
|
ae78ed26d1 |
Phase 1 review corrections — four bugs fixed
- relationships.pl: Replace recursive complementary_mitzvot/2 symmetry clause with explicit reverse facts (infinite loop in Prolog) - mitzvot.pl: Remove duplicate mitzvah(2, prohibition, no_other_gods) that caused double-counting in total_encoded/1 - resolve.pl: Add missing use_module(root_meanings) import — root_domain/2 was undefined, failing resolve_produces_result test - shoresh-engine: Generate and commit cabal.project.freeze for exact version pinning (Construction spec §1) All tests pass: 76 Elixir, 33 Haskell, 57 Prolog — 0 failures. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> |
||
|
Scott KarpandClaude Opus 4.6
|
af7522e977 |
Phase 2 review corrections — three spec violations fixed
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> |
||
|
Scott KarpandClaude Opus 4.6
|
5a93056af4 |
Step 15: Verification — the Shema Test
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> |
||
|
Scott KarpandClaude Opus 4.6
|
c67672777b |
Step 14: Connect components — chamishim karsay zahav
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> |
||
|
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> |
||
|
Scott KarpandClaude Sonnet 4.6
|
33f8b03583 |
Step 13: Korban Processor complete — 7 modules, 181 tests, all passing
- semichah: provenance tagging (6 sources, rejects empty/anonymous) - shechitah: strip preamble, self-reference, hedging, markdown, sycophancy - zerikah: extract Torah refs, Hebrew text, root analysis, insight markers - haktarah: transform prose to Prolog propositions (verse/3, root/2, claim/2, connection/3) - router: stateless routing — removed module-level _routing_log (kiyyor principle) - model_interface: outbound Claude API via httpx (Construction §3.4, HTTPS only) - hebrew_parser: nikkud/teamim stripping, consonant extraction, gematria, root identification All 5 BUILD_KORBAN.md verification tests pass. AGENTS.md: added structure_not_content.md to spec table, added Principle 6. build_log.md: recorded session, broken tablets #18-20, design decisions. Ka'asher tzivah Hashem et Moshe. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> |
||
|
Scott KarpandClaude Sonnet 4.6
|
80ec364da6 |
Phase 1-2 build: Steps 5-6, 8-13
Shoresh Engine (Haskell, Step 5) - 12 modules: Types, Lexicon, Binyanim, Teamim, Gematria, Graph, KetivQere, Smikhut, Havdalah, Kriah, KiTov, Firmware - 33 EUnit tests, 0 failures - Firmware module verifies L1 SHA-256 hash at startup Talmudic Engine (SWI-Prolog, Step 6) - 15 modules: halt, reasoning, specification, interface - 57 PlUnit tests, 0 failures - Three cardinal halt conditions: avodah_zarah, shfichut_damim, gilui_arayot Vav Pipeline (Elixir, Steps 8-11) - 14 modules: BereishitCycle, Shema, Cloud, Manna, L1Reader, Specification, HaltConditions, ShabbatTimer, CycleLog, Chatzotzrot, ShoreshEngineClient, TalmudicEngineClient, Application - 46 ExUnit tests, 0 failures - Nishma-first architecture: hears before it speaks Sanhedrin Framework (Erlang/OTP, Step 12) - 8 modules: sanhedrin_app, sanhedrin_sup, escalation, panel_sup, panel, judge, clerk, halt_monitor - 46 EUnit tests, 0 failures (includes fix: rejected outcome now reachable) - Panel sizes: 1/3/23/71 — unanimous capital guilty → acquit (Sanhedrin 17a) - Minority opinions append-only, never deleted Korban Processor (Python, Step 13) - 6 modules: korban, shechitah, semichah, zerikah, haktarah, router Builder tooling: AGENTS.md, opencode.json, memory/, src/tools/ Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> |
||
|
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> |