65 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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>	2026-04-28 19:31:58 -04:00
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>	2026-04-28 10:29:24 -04:00
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>	2026-04-28 09:36:16 -04:00
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 5e00f75) + parse_since/1 helper (graceful: bad input → all_time) + format_since/1 helper vav_pipeline/test/bigdei_kodesh_test.exs + 8 new tests covering: - 200 OK when no disposals recorded (empty L3) - response carries privacy_boundary statement - response carries disclosure block - since=invalid → all_time - since=valid_iso8601 → echoed - categorical_aggregate has all 3 slots even when empty - [@l3] aggregate counts categorically across multiple disposals - [@l3] PRIVACY BOUNDARY: response NEVER contains vidui item strings (load-bearing — verifies a known secret_phrase inserted into a vidui's chatot does NOT leak into the response body) Tests: vav_pipeline 361 passed, 0 failures, 35 excluded (was 353/33; +6 visible response-shape tests + 2 :l3-tagged tests). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-28 09:22:40 -04:00
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>	2026-04-28 09:16:21 -04:00
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>	2026-04-28 08:06:27 -04:00
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>	2026-04-28 08:02:09 -04:00
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>	2026-04-28 07:54:26 -04:00
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>	2026-04-28 07:49:15 -04:00
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>	2026-04-27 18:49:34 -04:00
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>	2026-04-27 16:07:44 -04:00
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>	2026-04-26 18:08:17 -04:00
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 0c4f764) added voice_profile to every ShemaContext — recording, per verse, the grammatical voice computed from OSHB morphology codes. Per-verse recording was the necessary precondition for what this commit does: WATCH the trajectory and FIRE when it stops oscillating between the singular and plural address poles. WHY THIS MATTERS: The Shema as recited oscillates between Devarim 6:4–9 (the singular pole — אֱלֹהֶיךָ, לְבָבְךָ) and Devarim 11:13–21 (the plural pole — אֱלֹהֵיכֶם, לְבַבְכֶם), and 11:14 famously switches poles mid-verse (אַרְצְכֶם 2mp → וְאָסַפְתָּ דְגָנֶךָ 2ms). The text REFUSES to stabilize at either pole. That refusal IS the anti-capture mechanism: - stuck at second_singular → gnostic-private capture - stuck at second_plural → mob-theology capture - stuck at first_* → operator-as-deity / calf (Shemot 32:4 — eleh elohekha Yisrael) Before this commit nothing observed the trajectory ACROSS verses. Per-verse profiles existed but nobody was watching the sequence; a system that read only Devarim 6:4–9 in a loop was producing a gnostic-shaped reception with no warning fired. The voice_profile field had a reader but no consumer. THE DETECTOR (VavPipeline.VoiceMonitor): A GenServer maintaining a sliding window of the dominant voice from the last N ShemaContexts (default N=10). The rule: - Window not yet full → :clear (insufficient evidence) - Window has both poles → :clear (the Shema is doing its job) - Address-only window missing one pole → {:missing_pole, :second_singular | :second_plural} - First-person majority → {:first_person_dominant, :first_singular | :first_plural} - Pure narration window → :clear (third-person sequences are NOT anti-Shema; the rule applies to ADDRESS, not to all voice) On a NEW alarm (different from the last fired), VoiceMonitor: 1. Logs a warning naming the specific stabilization shape with its Torah anchor and its capture-pattern name. 2. Fires Chatzotzrot.signal(:assembly_leaders, ...) so operators and kohanim subscribed to the chatzotzrot channel receive the alert. Re-firing is suppressed for as long as the same stabilization persists (no spam). The alarm clears when both poles return; a subsequent re-stabilization fires fresh. WIRING: - Shema.receive_context/1 and receive_context_at/2 now call VoiceMonitor.record(voice_profile) immediately after building the context. Process.whereis-guarded — the call is safe in tests that don't bring up the supervisor. - VoiceMonitor added to the supervision tree in application.ex. - Chatzotzrot.signal/2 itself is also Process.whereis-guarded inside VoiceMonitor (the existing pattern from manna_ledger, arei_miklat, urim_v_tumim). TESTS (test/voice_monitor_test.exs, 14 tests): - below window → :clear - all 2ms full window → fires {:missing_pole, :second_plural} - all 2mp full window → fires {:missing_pole, :second_singular} - both poles present → :clear - pure narration → :clear (third-person is not address) - first-person majority → {:first_person_dominant, _} - first-person tied (not strict majority) → does not fire - same stabilization persisting → last_alarm unchanged (no spam) - clear-then-stabilize-again → fresh alarm fires - reset/0 returns monitor to empty - record/1 with full voice_profile map (the Shema-side surface) Each test starts an isolated VoiceMonitor under a unique name (small window_size=4 for fast convergence) so tests don't share state. Chatzotzrot is intentionally NOT brought up — the monitor's guarded call falls through to log-only. Full vav_pipeline suite: 329 tests, 0 failures, 24 excluded (was 315 + 14 = 329). The 24 excluded are :l3-tagged tests needing PostgreSQL; unchanged. Closes Pass 2 finding A in full. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-26 16:25:59 -04:00
Scott KarpandClaude Opus 4.7	b1d5ac69e4	l3: validate coupling_trace at the write boundary (Elixir half of finding L) ... Companion commit to b254ee9 (Prolog Form 4 self_grounding) and 6b96250 (Prolog regression canary). Closes the Elixir half of Pass 2 finding L. THE GAP: The Prolog halt rules validate coupling traces as Prolog terms: a trace whose anchor is prior_decision/1, system_view/1, consensus/1, or interpretation/1 fires the self_grounding halt. But L3 stores traces as a list of strings (schema: {:array, :string}), serialized from Prolog. Inert string traces in L3 cannot be re-checked by Prolog halts. So the safety property the Prolog rules enforce stops at the Erlang/Elixir boundary — once a trace serializes into L3, no rule re-validates it. Worse: L3 is APPEND-ONLY (Architecture §3.7). Once a trace is in L3 it is permanent oral tradition; there is no path to retroactive correction. A future reader who pulls an L3 record and trusts the trace must be able to trust it was valid at the moment it became permanent. THE FIX: VavPipeline.L3.CouplingTrace (new) — Elixir-side validator that mirrors is_l1_grounded_coupling/1 in talmudic_engine/src/halt/ avodah_zarah.pl. Parses the string form (with a small balanced-paren parser so nested subjects like root(בער) don't break splitting) and recognizes exactly the three valid shapes: coupled(_, verse(BOOK, CHAPTER, VERSE)) coupled(_, mitzvah(ID)) coupled(_, mitzvah(ID), via_verse(BOOK, CHAPTER, VERSE)) Anything else fails. Empty traces are allowed at this layer (the empty-trace case is the golden_calf halt's domain in Prolog Form 2; L3 may legitimately store empty-trace records). L3.Store.record_interpretation/1 — gated. The new write path: case CouplingTrace.validate(coupling_trace) do :ok -> %Interpretation{} |> changeset(attrs) |> Repo.insert() {:error, :ungrounded, bad} -> {:error, {:ungrounded_coupling, bad}} end Validation fires BEFORE Repo.insert. An ungrounded trace can never become permanent oral tradition. CROSS-LANGUAGE INVARIANT: CouplingTrace.l1_grounded?/1 (Elixir) and is_l1_grounded_coupling/1 (Prolog) MUST stay aligned. If Prolog adds a new recognized shape, Elixir must add it too. Both module docstrings name this dependency explicitly. The next time CouplingTraceTest runs after a Prolog schema change, the Elixir tests catch the drift. ONE BUG CAUGHT WHILE WRITING: The first parser cut Hebrew root subjects mid-character because it used String.slice/3 with byte_size/1 as the codepoint length. Fixed to use binary_part/3 (since the trailing `)` is always one byte and the rest is opaque UTF-8). Test for Hebrew-root anchors now passes; documented inline so the trap is visible to future readers. TESTS: test/coupling_trace_test.exs (new, 22 tests): - all 3 valid shapes (verse, mitzvah, via_verse) including Hebrew root subject (catches the byte/codepoint bug) - all the predictable ungrounded shapes - malformed inputs (missing parens, wrong functor, wrong arity, empty string, non-string) - validate/1 list semantics (empty allowed, first-failure reported, mixed-trace caught) - parser robustness with deeply-nested subject parens test/l3_store_test.exs (extended, 5 new :l3-tagged tests): - record_interpretation refuses ungrounded trace - record_interpretation refuses mixed (good + bad) trace - record_interpretation accepts empty trace - record_interpretation accepts mitzvah-anchored trace - record_interpretation accepts 3-arg via_verse trace Full vav_pipeline suite: 315 tests, 0 failures, 24 excluded (24 = 19 pre-existing :l3 + 5 new :l3 store-gate tests; both need PostgreSQL). The 22 CouplingTrace unit tests run unconditionally and all pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-26 12:26:49 -04:00
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>	2026-04-26 12:19:55 -04:00
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>	2026-04-26 12:02:05 -04:00
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>	2026-04-26 12:01:41 -04:00
Scott KarpandClaude Opus 4.7	6b96250255	talmudic_engine: regression test — interpret/2 output must pass self_grounding halt ... Audit follow-up to commit b254ee9 (which added Form 4 self_grounding). Verified every coupling_trace construction site across the codebase (9 files) against is_l1_grounded_coupling/1: Production builders — SAFE: interpret.pl:128 — coupling_trace([]) empty triggers golden_calf (Form 2) only at non-low confidence, which is intentional interpret.pl:135 — coupling_trace(Couplings) where Couplings come from lines 76, 82, 104: coupled(domain(_), mitzvah(_)) OK coupled(root(_), mitzvah(_), via_verse(_,_,_)) OK coupled(root(_), verse(_,_,_)) OK all match is_l1_grounded_coupling/1. Different layer — SAFE: vav_pipeline/lib/.../l3/interpretation.ex — Ecto field is {:array, :string}. L3 stores SERIALIZED string traces, not Prolog terms. They are not parsed back into Prolog or re-checked by halt rules. (Separate concern from finding L: the round-trip loses schema, but this is L's concern, not D's.) Tests / pattern matching / docs — SAFE: read positions, deliberate ungrounded test cases, comments only. Conclusion: no production path trips the new self_grounding halt. To prevent FUTURE schema drift in interpret.pl from silently introducing ungrounded coupling shapes (which would then trip the halt on real pipeline output), added two regression tests in interpret_self_grounding_regression suite: 1. interpret_output_does_not_self_ground — runs interpret/2 on a real case and asserts halt_check_self_grounding does not fire. 2. every_interpret_coupling_is_l1_grounded — stronger: every coupling individually passes is_l1_grounded_coupling/1. If anyone adds a new coupling shape to interpret.pl that does not match the recognized L1 anchors (e.g. coupled(_, prior_decision(_)), coupled(_, system_view(_))), these tests fail BEFORE the schema drift becomes a production halt. The canary is in the same suite as the halt rule it protects. Test results: halt_test 47/47 (was 45, +2). Full Prolog suite 212/212 across all six test files. Closes the verification half of Pass 2 finding L (coupling_trace end-to-end population) for the Prolog layer. The Elixir L3 round-trip is a separate concern — traces stored as strings cannot be re-validated — and remains tracked under finding L. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-26 11:45:16 -04:00
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>	2026-04-26 11:38:39 -04:00
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>	2026-04-24 19:25:44 -04:00
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>	2026-04-24 18:58:14 -04:00
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>	2026-04-24 17:31:37 -04:00
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>	2026-04-23 17:23:13 -04:00
Scott KarpandClaude Opus 4.6	e223ab15b3	Phase 4 complete: Steps 21, 22, 24 — Korban external integration, L2 Urim v'Tumim, Kushya generator ... Vayikra 9:24 — vatetzei esh milifnei Hashem vatokhal al hamizbeach. Phase 4 of the architecture is now complete. The remaining three steps that were marked "blocked on external infrastructure" are built — discipline-respecting, eish-zarah-aware, and tested. ## Step 22 — Korban Processor external model integration (korban_processor/src/korban_processor/external_offering.py) The single legitimate entry point for external model consultation. Wraps Claude API calls through the offering protocol so external output is treated as korban (raw material), never authoritative: - semichah — provenance is tagged (avodah zarah Form 1 prevention) - shechitah — assistant voice, hedging, formatting stripped - zerikah — vital content extracted - haktarah — converted to Prolog propositions - route — sent to internal component per offering type The raw Korban is preserved on the ProcessedKorban (gilui arayot Form 3 prevention — input/output coupling never severed). No internal component should call call_claude() directly. 11 tests, mocked external calls. Live API test opt-in via SHORASHIM_LIVE_API=1. ## Step 24 — L2 Urim v'Tumim interface (vav_pipeline/lib/vav_pipeline/urim_v_tumim.ex) PRD §4.7: housed in the kohen gadol's breastplate; consulted only on high-stakes decisions where normal deliberation is insufficient. Bamidbar 27:21 — al-piv yetz'u v'al-piv yavo'u. Three escalation steps, three honest outcomes: 1. resolved_by_specification — re-read produced an answer 2. resolved_by_external — external testimony recorded (NOT binding) 3. deferred_to_human — the system stops, asks for human judgment Pre-condition gating refuses cases that didn't reach Sanhedrin teiku first (no preempting deliberation) or that aren't flagged high-stakes (ordinary teiku stays teiku). Records every consultation with steps taken — there is no quiet escalation. Per PRD: "The Urim v'Tumim never fabricates certainty where none exists." When external also fails, the system stops. It does not proceed on a guess. Added to VavPipeline supervision tree. 14 tests. ## Step 21 — Kushya generator scaffolding (kushya_generator/) Directory layout per Architecture §3.6 with three layers: - data/training_pairs/seed_pairs.jsonl — 10 hand-curated bootstrap pairs covering 9 kushya types (scope_narrowing, internal_tension, harmonization, exception_test, edge_case, scope_application, rabbinic_constraint, method_question, subject_identification) - data/prepare_training.py — validates the four kushya requirements (specific Torah passage, identified weakness, question form, non-trivial), produces train.jsonl + eval.jsonl with stratified 80/20 split by type - fine_tune/config.yaml + train.py — QLoRA configuration and training script. Operator's task — needs GPU. Script is complete and self-contained. - inference/kushya_api.py — three-backend interface (fine_tuned → external → fallback). When fine-tuned model isn't deployed, falls back to external via Korban Processor (Step 22). The fallback is honest: returns no kushya rather than inventing one. The Talmudic Engine's rule-based challenge.pl remains the primary kushya source. 17 tests covering dataset validation, backend selection, and reference extraction. ## .gitignore fix The earlier "data/" line was too broad — it caught kushya_generator/data/. Scoped to /data/ (root-level only). ## Test counts - Elixir: 274 (was 260; +14 for UrimVTumim) - Korban Python: 196 + 1 skipped (was 195; +1 module = 11 tests) - Kushya Python: 17 (new) - Haskell: 33 (unchanged) - Prolog: 195 (unchanged) - Total: 715 + 19 L3 excluded ## Phase 4 status All 12 steps now have implementations: - Steps 23, 25, 26, 27, 28, 29, 30, 31, 32: complete - Steps 21, 22, 24: complete with discipline preserved Step 21's fine-tuning run remains the operator's GPU task; the pipeline is built such that a deployed adapter slots into the inference backend without touching the Talmudic Engine or anything above. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-04-23 17:12:03 -04:00
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>	2026-04-21 13:11:52 -04:00
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>	2026-04-21 09:49:59 -04:00
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>	2026-04-21 09:24:44 -04:00
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>	2026-04-21 09:03:57 -04:00
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>	2026-04-21 08:54:54 -04:00
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>	2026-04-21 08:20:01 -04:00
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>	2026-04-21 08:19:33 -04:00
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>	2026-04-21 08:09:53 -04:00
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>	2026-04-20 17:04:40 -04:00
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>	2026-04-20 12:42:07 -04:00
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>	2026-04-17 14:53:30 -04:00
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>	2026-04-16 22:21:13 -04:00
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>	2026-04-16 14:02:45 -04:00
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>	2026-04-01 13:16:31 -04:00
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>	2026-03-30 21:45:42 -04:00
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>	2026-03-30 21:24:15 -04:00
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>	2026-03-29 17:30:31 -04:00
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>	2026-03-29 17:25:23 -04:00
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>	2026-03-29 12:52:07 -04:00
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>	2026-03-22 13:38:34 -04:00
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>	2026-03-22 07:32:15 -04:00
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>	2026-03-22 07:11:02 -04:00
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>	2026-03-22 06:53:25 -04:00
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>	2026-03-18 09:27:09 -04:00
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>	2026-03-18 08:59:08 -04:00
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>	2026-03-17 15:50:36 -04:00