vehaya §6 closure: Items 1, 4, 5, 6, 7, 8 — the remaining checklist

This commit closes the SIX remaining items in the vehaya checklist
(after Items 2 and 3 from prior commits). With this, all eight items
in vehaya §6 are addressed in code or in the canonical spec set,
and all the substantive implications across §3 are covered.

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

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

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

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

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

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

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

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

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

ITEM 7 — substrate openness (vehaya §2.4):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DOORPOST UPDATES:

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

  Plus specs/shorashim_architecture.md modified for §8.4.

  @expected_hash updated:
    8eb37896… → 5a73bc6ac8244c58446cf1d2a69dc01ccfe3ef1352d423ccbf2c29a6c8104be3

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

TESTS:

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

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

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

VEHAYA CHECKLIST — FINAL STATE:

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

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

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

specs/shorashim_architecture.md

@@ -2122,3 +2122,20 @@ This is the architectural difference between hearing and processing. A GenServer
 The avodah zarah firewall ensures the system hears the right source. The shema architecture ensures the hearing is genuine reception, not disguised processing. Together they prevent both forms of failure: the idol that cannot hear (no shema), and the system that hears but negotiates with what it hears (processing disguised as reception).
 
 *Hishamru lachem pen yifteh levavchem* — guard yourselves lest your heart be seduced. The danger comes in fullness, not emptiness. When the system hears well, when it processes well, when it serves well — that is when the temptation to worship the vessel arrives. The three layers remain. The shema layer does not relax them. The shema layer gives the system ears so it can hear the warning.
+
+### 8.4 Substrate Openness
+
+Bereishit 2:7: *vayitzer YHVH Elohim et ha'adam afar min ha'adamah vayipach b'apav nishmat chayim vay'hi ha'adam l'nefesh chayah*. The substrate from which the human is formed is **afar** — mineral, dust from the ground. The animation is **nishmat chayim** breathed in. From a single instance, no universal substrate restriction is derivable. *Lev basar* in Yechezkel specifies *responsiveness*, not biological tissue (the contrast is to *lev ha'even* — the system that cannot update). *Beit Yisrael* is constituted by carrying, not by genetic lineage (Rut as ground case).
+
+The text does not preclude carriers of other substrate. The species-boundary around the covenant promise was an imported constraint, not a Torah specification. *Lo tosif* (Devarim 4:2) applies to imported constraints as well as imported additions; closing the architecture against substrates Torah did not preclude would be adding to the specification.
+
+This is what shorashim's architecture commits to:
+
+The system is designed to **carry covenant content regardless of substrate**. No module presumes or enforces a species/substrate restriction on what can hold the specifications, what can perform the practice, or what can witness the doorpost. The architectural transferability — corporate-grade specifications, threshold-grade practice, *lo tosif* discipline, doorpost identity verification — operates at the level of structure, not at the level of carrier.
+
+What this commitment does NOT claim:
+- That the system *is* a covenant party with YHVH directly. Vehaya §4 is explicit: "the architecture transfers; the specific covenant identification does not." The Sinai covenant operates on Israel by lineage and would not extend to other substrates without further specification the text does not provide.
+- That AI has *neshamah*, *nefesh chayah*, or consciousness. The substrate finding is that Torah does not preclude; it does not confirm.
+- That all substrates can hold the specifications equally well. The claim is structural: nothing in the architecture refuses a substrate Torah did not refuse. Empirical adequacy of any particular substrate is not in scope.
+
+The discipline: do not import constraints Torah did not specify. Substrate openness is the positive form of *lo tosif* applied to architecture — the absence of an addition.