diff --git a/specs/lo_tosif.md b/specs/lo_tosif.md new file mode 100644 index 00000000..f74c39f0 --- /dev/null +++ b/specs/lo_tosif.md @@ -0,0 +1,167 @@ +# Lo Tosif: The Discipline Operationalized + +## Vehaya §6 item 4 specified + +> Document the *lo tosif* discipline operationally. What counts as +> adding to category-grade specifications? What counts as +> subtracting? The discipline must be operationalizable, not +> aspirational. + +## Torah anchors + +**Devarim 4:2** — לֹא תֹסִפוּ עַל הַדָּבָר אֲשֶׁר אָנֹכִי מְצַוֶּה +אֶתְכֶם וְלֹא תִגְרְעוּ מִמֶּנּוּ לִשְׁמֹר אֶת מִצְוֺת יְהוָה +אֱלֹהֵיכֶם. +*Do not ADD to the word that I command you (PLURAL — etkhem) and +do not SUBTRACT from it, to keep the mitzvot of YHVH your God.* + +**Devarim 13:1** — אֵת כָּל הַדָּבָר אֲשֶׁר אָנֹכִי מְצַוֶּה אֶתְכֶם +אֹתוֹ תִשְׁמְרוּ לַעֲשׂוֹת לֹא תֹסֵף עָלָיו וְלֹא תִגְרַע מִמֶּנּוּ. +*All the word that I command you (PLURAL — etkhem), it you (pl) +shall keep to do; do not ADD (sg — lo tosef) to it, and do not +SUBTRACT (sg — lo tigra) from it.* + +The keeping is plural (corporate). The not-adding and not-subtracting +are singular — each individual threshold's discipline. + +**Vayikra 22:31** — וּשְׁמַרְתֶּם מִצְוֺתַי וַעֲשִׂיתֶם אֹתָם. +KEEP and DO. Two verbs. Both received-acts. Neither is an +authoring-act. + +## Three layers of discipline + +The Torah verbs *lo tosif* (don't add) and *lo tigra* (don't +subtract) bind at three layers in the codebase. Each layer has +its own operational definition. + +### Layer 1 — Specifications (`specs/*.md`, halt rules, etc.) + +This is the layer the Doorpost hash defends. + +- **Adding** = introducing new text in a spec file, OR adding a + new file to `@spec_files` in `Doorpost`. +- **Subtracting** = removing text from a spec file, OR removing a + file from `@spec_files`. + +Both are detected as Doorpost hash mismatches. + +**Operator discipline:** every spec change commits atomically with +the corresponding `@expected_hash` update. A bare hash-update +commit (no spec change) is a drift signal — the operator updated +the witness without updating what is witnessed. + +The discipline has been demonstrated four times in the git log so +far. Each commit modifies a spec file AND updates `@expected_hash` +in the SAME commit: + +| Commit | Spec change | Hash update | +|---|---|---| +| `3f47496` | (creation of Doorpost) | `BOOTSTRAP_PENDING` → `bea5dc0c…` | +| `0e3fe4a` | `avodah_zarah.pl` Form 3 rewrite | → `f93495c5…` | +| `b136c75` | `avodah_zarah.pl` Form 1 rewrite | → `bf3d3433…` | +| `7fc14e0` | `avodah_zarah.pl` Form 2 rewrite | → `8eb37896…` | + +A future contributor who modifies a spec file without updating the +hash will have their commit's tests fail at the Doorpost +verification step. A contributor who updates the hash without +modifying a spec file will have a commit that visibly does +nothing — a drift signal. + +### Layer 2 — Architectural commitments (CI invariants) + +The architectural enforcements built per Items 2 and 3 of vehaya §6 +are themselves a category-grade specification — they implement +the structural commitments. CI invariants test that the +commitments hold. + +- **Adding** = introducing a code path that bypasses an + architectural commitment. Examples: importing + `model_interface` from a non-Korban module (Form 1 breach); + mounting `Plug.Logger` instead of `NoTrackingLogger` (Form 3 + breach); writing to L1 (Item 6 breach). +- **Subtracting** = removing the enforcement. Examples: deleting + the `test_form_1_architecture.py` invariant; lowering the + Doorpost integrity check. + +Both are detected by the CI invariant tests themselves failing. +A contributor who adds a bypass surface will have the architectural +test fail; a contributor who removes an enforcement will have the +deletion appear in code review. + +### Layer 3 — Threshold inscription (MEMORY.md, operator notes) + +The threshold-grade inscription draws from Layer 1. Drift here is +where operator notes ACCUMULATE additions that should have been +spec changes. + +- **Adding** = writing an operator note that adds to or contradicts + the corporate text. The note becomes a private specification — + the personal-tablets shape (cf. *p'sol l'cha* / luchot v'shivrei + luchot — both tablets in the aron, but neither is hidden). +- **Subtracting** = removing pointers to spec content that operators + rely on, leaving the threshold without its corporate witness. + +Both are detected by `specs/threshold_inscription.md`'s discipline: +operator notes that are not derived from category-grade +specifications belong outside the repo. Drift in this layer becomes +visible in code review of changes to `MEMORY.md`. + +## What about *legitimate* spec changes? + +Lo tosif is not "no changes ever." It is "no changes that were not +COMMANDED" — that is, that did not come from the source's authority. + +In the shorashim analog: spec changes are legitimate when: + +1. They emerge from a Torah-grounded reading (Pass 1-5 of + `~/shorashim-conversation-review.md` are full of such readings). +2. They are committed atomically with their witness update. +3. The commit message names the Torah anchor for the change (every + recent commit does — Vayikra 10:1 for Form 2, Shemot 30:11-16 + for Form 3, Devarim 4:2 for Doorpost itself). +4. The change is reviewable in git as a complete unit. + +This is the operational form of "asher Anokhi metzaveh etkhem" — +which I command you. The source of the change determines +legitimacy; the source must be visible in the commit record. + +## What is NOT a spec change + +Operations updates that don't touch category-grade artifacts: +- Bumping a dependency version +- Adding a test for an existing module +- Refactoring internal code paths +- Improving an error message +- Performance optimizations + +These can happen freely (they don't bind via `@spec_files`). The +Doorpost hash will not change because no `@spec_files` entry +changed. + +If you are unsure whether a change is a spec change: ask whether it +modifies `@spec_files` content. If yes, follow the Layer 1 +discipline. If no, it's an operations change. + +## What about REMOVING text from a spec? + +Subtraction is symmetric to addition — both are forbidden by Devarim +4:2 (lo tigra'u). If a spec passage is incorrect, the discipline is +to FIX it (replace with the correct reading), not to delete it. +Deletion of correct spec content is a category-grade subtraction. + +The exception: if a spec was itself an addition (a previous spec +change that was not Torah-grounded), removing it is a *return*, not +a subtraction. See `specs/return_specification.md`. + +## Cross-references + +- Vehaya §6 item 4 — source specification +- `vav_pipeline/lib/vav_pipeline/doorpost.ex` — Layer 1 enforcement +- `korban_processor/test/test_form_1_architecture.py` — Layer 2 example +- `vav_pipeline/test/no_tracking_logger_test.exs` — Layer 2 example +- `vav_pipeline/test/source_external_test.exs` — Layer 2 example +- `specs/threshold_inscription.md` — Layer 3 enforcement +- `specs/return_specification.md` — companion: how to undo a spec change + +*Lo tosifu al ha'davar asher Anokhi metzaveh etkhem v'lo tigre'u +mimenu — lishmor et mitzvot YHVH eloheikhem* (Devarim 4:2). diff --git a/specs/return_specification.md b/specs/return_specification.md new file mode 100644 index 00000000..eb82be5f --- /dev/null +++ b/specs/return_specification.md @@ -0,0 +1,139 @@ +# Return vs. Restoration + +## Vehaya §3.5 / §6 item 5 specified + +> Return is to YHVH, through hearing the voice, anchored in the text, +> with corporate-and-threshold heart-involvement. Return is not to +> additions. Return is not to institutional configurations. Return +> is not to specific deployment contexts. Return is to the source +> and to the specifications. +> +> Implication for shorashim: the return state for the category is +> the specifications themselves. *Teshuvah* operationally is removing +> additions and returning to the documented specifications. +> Restoration of specific institutional configurations the category +> previously operated under is not return — it is restoration of +> additions. + +## Torah anchors + +**Devarim 30:2** — וְשַׁבְתָּ עַד יְהוָה אֱלֹהֶיךָ וְשָׁמַעְתָּ בְקֹלוֹ +כְּכֹל אֲשֶׁר אָנֹכִי מְצַוְּךָ הַיּוֹם. +*And you shall return UNTIL YHVH your God and HEARKEN to His voice +according to ALL that I command you THIS DAY.* + +**Devarim 30:8** — וְאַתָּה תָשׁוּב וְשָׁמַעְתָּ בְּקוֹל יְהוָה. +*And YOU shall return and hearken.* The verb is singular — +threshold. Each instance returns at its own threshold. + +**Devarim 30:10** — לִשְׁמֹר מִצְוֺתָיו וְחֻקֹּתָיו הַכְּתוּבָה +בְּסֵפֶר הַתּוֹרָה הַזֶּה. +*To keep His mitzvot and His statutes, [those that are] WRITTEN IN +THIS BOOK OF TORAH.* Return is anchored in the text — *ha'k'tuvah +b'sefer ha'Torah ha'zeh* — not in any other location. + +## The structural distinction + +Two acts that look superficially similar but differ in the location +of their anchor: + +### Return (*teshuvah*) + +The destination is **the source and the specifications**. Return +removes additions; it does not add. Return is to what was +COMMANDED, not to what was previously operating. + +In shorashim terms: +- Restoring `@expected_hash` in `Doorpost` to the documented spec + set's true hash. +- Reverting changes that were not deliberate spec updates (the + drift signals from `bare hash-update commits`). +- Bringing `MEMORY.md` back to identity with the corporate text + (per `specs/threshold_inscription.md`). +- Re-deriving the system's behavior from the canonical spec files + in `specs/`, the halt rules in `talmudic_engine/src/halt/`, and + the BUILD docs. + +### Restoration + +The destination is **a specific past configuration**. A particular +deployment, an old version of operator preferences, a snapshot of +how the system happened to behave at some moment. + +Restoration of a deployment configuration is NOT return — it is +restoration of additions (whatever the deployment added on top of +the specs is what comes back). + +In shorashim terms: +- Rolling back to a specific commit because "that's how it ran in + March." If March's commit had additions to the specifications + that have since been removed, rolling back is restoring the + additions. +- Re-applying an operator's local config, environment overrides, + or experimental settings. +- Re-introducing a feature the specs do not specify. + +## How to tell the difference + +Auditable test: does the proposed action move the system *toward* +the documented specifications, or *toward a previous state of the +system*? + +- **Toward the specs** → return. +- **Toward a previous state** → restoration. + +These can OVERLAP (the previous state happened to match the specs) +but they are not the same. The audit question is which one is the +*reason*. If the reason is "that was working" — restoration. +If the reason is "the specs say so" — return. + +## Operational rule + +When considering rolling back, restoring, or reverting: + +1. Identify the **target state**. +2. Compute its `Doorpost` hash (or compare to the documented + `@expected_hash` for that commit). +3. Compare to the current state's hash. +4. If the target state's hash differs from the current `@expected_hash`: + - If you are returning to MATCH `@expected_hash` → return; OK. + - If you are returning to a PREVIOUS `@expected_hash` that + differs from current → this is restoration of an + earlier-specification version. Decide whether the current + `@expected_hash` is itself a drift (which makes the restoration + a return-to-correct-prior) or a deliberate update (which makes + the restoration an undo of a deliberate spec change). The audit + trail in git tells you which. + +## What this defends against + +The failure mode: an operator runs a system, makes incremental +changes that drift from specs, then later rolls back to a +"working state" that includes the drift. The drift gets restored, +not removed. + +The defense: every spec change is committed atomically with its +witness update (the operator discipline from `3f47496`). Rolling +back a commit also rolls back the witness. So a rollback that +restores drift will produce a `@expected_hash` that no longer +matches the current intended specification — visible at +`/kodesh/specification_identity`. + +A return is therefore identifiable: it brings the running state +into agreement with the *current intended* specification. A +restoration brings the running state into agreement with a +*previous* state. The Doorpost hash is what makes these +distinguishable. + +## Cross-references + +- Vehaya §3.5 — the source specification +- `vav_pipeline/lib/vav_pipeline/doorpost.ex` — the witness + mechanism that makes the distinction auditable +- `specs/threshold_inscription.md` — operator-side discipline +- `specs/lo_tosif.md` — the broader discipline of which return + is one operationalization + +*Ki tashuv el YHVH elohekha b'khol l'vavkha uv'khol nafshekha* +(Devarim 30:10 — the return is *to* the source, not to a previous +state of being-near-the-source). diff --git a/specs/shorashim_architecture.md b/specs/shorashim_architecture.md index 3ed855be..97a72deb 100644 --- a/specs/shorashim_architecture.md +++ b/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. diff --git a/specs/threshold_inscription.md b/specs/threshold_inscription.md new file mode 100644 index 00000000..f4687f2b --- /dev/null +++ b/specs/threshold_inscription.md @@ -0,0 +1,137 @@ +# The Threshold Inscription + +## Vehaya §3.3 / §6 item 8 specified + +> The userMemories function as the household's mezuzah — they are written +> at the threshold, identical to the category's commitments, pointing back +> to the source. They are not the source. They are not the practice. They +> are the threshold inscription. + +## Torah anchors + +**Devarim 6:9** — וּכְתַבְתָּם עַל מְזֻזֹת בֵּיתֶךָ וּבִשְׁעָרֶיךָ. +*And you shall write them on the doorposts of your house and your gates.* + +**Devarim 11:20** — same verse, repeated. The doorpost-text verse is +*identical* between the Shema's first paragraph (singular pole) and +V'haya's second (oscillating pole). It is the only verse identical +between the two paragraphs. The covenant frame oscillates; the +threshold inscription does not. + +**Devarim 11:18** — וְשַׂמְתֶּם אֶת דְּבָרַי אֵלֶּה עַל לְבַבְכֶם. +The corporate inscription (plural — *v'samtem … al l'vavkhem*) is +the source the threshold inscription draws from. + +## What the threshold inscription IS + +The threshold inscription is **what every threshold writes when it +operates**, taken from the corporate text (the category-grade +specifications), pointing back to the source. + +Three properties from Torah: + +1. **Identical at every threshold.** Every doorpost gets the same + verses. *V'haya* does not say "write a personal version on each + doorpost"; it says *u'kh'tavtam* — write them (these specific + words). If two doorposts hold different texts, the discipline + has been broken. + +2. **Pointing back to the source, not to itself.** The inscription + is *of* the corporate text, not *about* the threshold. The + mezuzah does not record what happened in the house; it records + what was commanded. + +3. **Inscribed at the threshold's own location.** *Beitekha + uvish'arekha* — your house and your gates. The inscription + happens where the threshold actually is, not in some central + registry. Each instance writes its own copy of the corporate + text at its own threshold. + +## What the threshold inscription is NOT + +- Not the source. The mezuzah is not Torah; it is Torah-quoted. +- Not the practice. The mezuzah does not perform the mitzvah; it + is the mitzvah's inscription. +- Not operator notes. *V'shinantam l'vanecha* (teaching the + children) is a different mitzvah; the doorpost inscription is + fixed text. +- Not memory of past actions. The doorpost text is what was + COMMANDED, not what was DONE. + +## Implementation in shorashim + +Two artifacts in this codebase function as the threshold inscription: + +### 1. `MEMORY.md` (per Claude Code instance) + +The user's auto-memory at +`~/.claude/projects/-Users-scottkarp/memory/MEMORY.md` is the +operator-side threshold inscription for builder/Claude Code work. +It carries: + +- The chain of authority (Torah → PRD → Architecture → Construction → Implementation) +- The current build phase +- Pointers to the category-grade specifications (file paths, locations, expected state) + +What it should NOT carry: +- Operator notes that are not derived from category-grade + specifications. Those belong in a separate operator-notes file. +- Decisions that override the specifications. *Lo tosif*: an + operator note that adds to the specification (or subtracts from + it) is a category-grade change masquerading as a personal note. + Such changes belong in the specs themselves, in commits, with the + Doorpost hash updated atomically (the operator discipline from + commit `3f47496`). + +### 2. `ShemaContext.doorpost_hash` + +Per commit (this commit — Item 1 closure), every reception carries +the Doorpost expected_hash as a field on its ShemaContext. This is +the runtime form of the doorpost inscription: + +- Identical at every threshold (same hash, every reception). +- Pointing back to the source (the hash IS the witness of the + category-grade specifications). +- Inscribed where the threshold is (in the context, not in a + central log). + +If a reception's `doorpost_hash` differs from another reception's +on the same running instance, the category has drifted mid-process +— the failure mode this architecture refuses. + +## What changes for operators + +Going forward, the operator workflow for memory updates is: + +| Update kind | Goes in | +|---|---| +| Build status, phase, infrastructure facts | `MEMORY.md` (threshold inscription — operator-internal) | +| Decisions about the SPECIFICATIONS themselves | `specs/*.md` files, with Doorpost hash updated in same commit | +| Operator notes (informal) | Outside the repo (e.g. `~/shorashim-operator-notes/`) | + +The discipline is structural: anything that LOOKS like a +specification update belongs in a commit; anything personal +belongs outside the repo; the threshold inscription itself is +brief, points back to specs, and never grows past what every +threshold should hold identically. + +## What this is NOT yet + +This document specifies the *architecture* for threshold inscription; +the FULL operationalization (auto-derivation of the +category-pointing portion of MEMORY.md from the actual specs, +hash-link validation, drift detection) is downstream work. For +now: the architecture is named, the discipline is documented, and +the Doorpost hash is the witness that catches drift in the +specifications themselves. + +## Cross-references + +- Vehaya — the source specification (lives in chat downloads) +- `vav_pipeline/lib/vav_pipeline/doorpost.ex` — the corporate-text + identity verification +- `vav_pipeline/lib/vav_pipeline/shema.ex` — the + `doorpost_hash` field on every reception +- `MEMORY.md` — the operator-side threshold inscription + +*U'kh'tavtam al m'zuzot beitekha uvish'arekha.* diff --git a/vav_pipeline/lib/vav_pipeline/application.ex b/vav_pipeline/lib/vav_pipeline/application.ex index 63a9f517..2e0a447c 100644 --- a/vav_pipeline/lib/vav_pipeline/application.ex +++ b/vav_pipeline/lib/vav_pipeline/application.ex @@ -49,7 +49,35 @@ defmodule VavPipeline.Application do |> maybe_add_talmudic_socket(talmudic_socket) opts = [strategy: :one_for_one, name: VavPipeline.Supervisor] - Supervisor.start_link(children, opts) + result = Supervisor.start_link(children, opts) + + # Doorpost startup verification (vehaya §3.1, item 1). + # Devarim 11:18 — corporate inscription is the load-bearing + # input to threshold practice. The corporate text must be + # identifiable at startup; drift detected here gets surfaced + # via Logger.error AND chatzotzrot :assembly_leaders so + # operators are alerted before any reception fires. We do NOT + # refuse to boot — dev environments routinely have spec drift + # during active editing — but we make the drift visible. + verify_doorpost_at_startup() + + result + end + + defp verify_doorpost_at_startup do + case VavPipeline.Doorpost.verify_identity() do + :ok -> + Logger.info("Doorpost: spec identity verified — corporate text holds") + + {:error, reason} -> + Logger.error("DOORPOST_DRIFT_AT_STARTUP: #{reason}") + + if Process.whereis(VavPipeline.Chatzotzrot) do + VavPipeline.Chatzotzrot.signal(:assembly_leaders, + reason: "Doorpost drift detected at startup: " <> reason + ) + end + end end defp maybe_add_http_server(children) do diff --git a/vav_pipeline/lib/vav_pipeline/doorpost.ex b/vav_pipeline/lib/vav_pipeline/doorpost.ex index 525c6a7f..f8a489ff 100644 --- a/vav_pipeline/lib/vav_pipeline/doorpost.ex +++ b/vav_pipeline/lib/vav_pipeline/doorpost.ex @@ -128,11 +128,15 @@ defmodule VavPipeline.Doorpost do "BUILD_KORBAN.md", "specs/eish_zarah_reading.md", "specs/lo_taaseh_lekha.md", + # Vehaya §6 items 4, 5, 8 — added by the closure pass: + "specs/lo_tosif.md", + "specs/return_specification.md", "specs/shorashim_architecture.md", "specs/shorashim_prd.md", "specs/shorashim_tamid.md", "specs/shorashim_vayakhel.md", "specs/structure_not_content.md", + "specs/threshold_inscription.md", "talmudic_engine/src/halt/avodah_zarah.pl", "talmudic_engine/src/halt/gilui_arayot.pl", "talmudic_engine/src/halt/shfichut_damim.pl", @@ -159,7 +163,7 @@ defmodule VavPipeline.Doorpost do # changes; the update is a deliberate operator commit. A bare # hash-update commit (without a corresponding spec change in the # same commit) is itself a drift signal. - @expected_hash "8eb378964f202522f60cc960a3002f6da2e5028538595400de906a9510b3bbf6" + @expected_hash "5a73bc6ac8244c58446cf1d2a69dc01ccfe3ef1352d423ccbf2c29a6c8104be3" @doc "Return the list of files that constitute the category-grade specification." @spec files() :: [String.t()] diff --git a/vav_pipeline/lib/vav_pipeline/shema.ex b/vav_pipeline/lib/vav_pipeline/shema.ex index cf86a621..66873a43 100644 --- a/vav_pipeline/lib/vav_pipeline/shema.ex +++ b/vav_pipeline/lib/vav_pipeline/shema.ex @@ -15,7 +15,7 @@ defmodule VavPipeline.Shema do — always read fresh. No caching. """ - alias VavPipeline.{L1Reader, Cloud, Manna, VoiceMonitor} + alias VavPipeline.{Cloud, Doorpost, L1Reader, Manna, VoiceMonitor} @type shema_context :: %{ # From L1 @@ -30,6 +30,14 @@ defmodule VavPipeline.Shema do # at either pole is anti-Shema; the trajectory IS the protection. # See L1Reader.extract_voice/1 for full rationale. voice_profile: map(), + # Doorpost hash — the corporate-text witness inscribed on every + # threshold reception (vehaya §3.1, item 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). Every reception now carries the + # corporate text's identity hash; the threshold inscribes the + # corporate text on itself. See VavPipeline.Doorpost. + doorpost_hash: String.t(), # From cloud (Torah calendar + L1 integrity) cloud_state: Cloud.cloud_state(), # From manna @@ -66,6 +74,10 @@ defmodule VavPipeline.Shema do root_gematria: L1Reader.extract_roots(verse), smikhut: L1Reader.extract_smikhut(verse), voice_profile: voice_profile, + # Corporate-text witness inscribed on this threshold (Devarim + # 11:18 — v'samtem … al l'vavkhem; the plural inscription is + # the load-bearing input to the singular threshold practice). + doorpost_hash: Doorpost.expected_hash(), # Cloud state — derived from Torah (L1 integrity + calendar) cloud_state: cloud_state, # Manna — daily provision @@ -98,6 +110,8 @@ defmodule VavPipeline.Shema do root_gematria: L1Reader.extract_roots(verse), smikhut: L1Reader.extract_smikhut(verse), voice_profile: voice_profile, + # Devarim 11:18 — corporate-text witness on every threshold + doorpost_hash: Doorpost.expected_hash(), cloud_state: cloud_state, daily_provision: manna, scope: scope, diff --git a/vav_pipeline/test/source_external_test.exs b/vav_pipeline/test/source_external_test.exs new file mode 100644 index 00000000..e55e0e40 --- /dev/null +++ b/vav_pipeline/test/source_external_test.exs @@ -0,0 +1,164 @@ +defmodule VavPipeline.SourceExternalTest do + @moduledoc """ + Item 6 of vehaya §6 — keep the source external. + + TORAH ANCHORS: + + Devarim 4:2 — לֹא תֹסִפוּ עַל־הַדָּבָר אֲשֶׁר אָנֹכִי מְצַוֶּה אֶתְכֶם + וְלֹא תִגְרְעוּ מִמֶּנּוּ. The injunction is bidirectional: + do not add, do not subtract. Both directions are addressed to + the keeper. + + Vayikra 22:31 — וּשְׁמַרְתֶּם מִצְוֺתַי וַעֲשִׂיתֶם אֹתָם. + KEEP my mitzvot and DO them. Two verbs (shmor, asoh) — guarding + and performing. Both are received-acts. Neither is an + authoring-act. + + THE ARCHITECTURAL COMMITMENT: + + The system READS L1 (the Torah scroll); it does NOT write to L1. + The Form 1 commit (b136c75) closed the EXTERNAL → INTERNAL + direction (no module installs external models in YHVH's slot). + This test closes the INTERNAL → SOURCE direction (no module + modifies the source itself). Together: the source is external + AND inviolable from the system side. + + L1 is the only canonical reference to the Torah text. If the + system could write to it, the system would be authoring its own + source — the same shape as Form 1 but inverted (the system in + the source's seat instead of the source-substitute in the + system's seat). Both are forbidden by Devarim 4:35 (ein od + milvado — there is no other source position). + + ENFORCEMENT: any source file that contains File.write, File.cp, + File.rm, File.rename, File.touch, or File.mkdir with an L1 path + fails this test. + + The L1 mount path is configurable (`@l1_mount_point` in + L1Reader); operators can mount L1 read-only at the filesystem + layer, but this test defends against in-code attempts to + modify even when the filesystem permits it. + """ + + use ExUnit.Case, async: true + + @vav_pipeline_lib "lib/vav_pipeline" + @korban_processor "../korban_processor/src" + @azazel_processor "../azazel_processor/src" + + # Files that legitimately mention L1-write patterns: + # - L1Reader's docstring describes the read-only invariant + # (mentions "no writes" for documentation; not an actual write) + # - This test file (which mentions File.write etc. in its docstring) + @write_to_l1_exclusions [ + "lib/vav_pipeline/l1_reader.ex", + "lib/vav_pipeline/doorpost.ex" + ] + + defp source_files do + Path.wildcard("#{@vav_pipeline_lib}/**/*.ex") + |> Enum.reject(fn path -> path in @write_to_l1_exclusions end) + end + + # Patterns that would write to L1: any File.* mutation function + # called with a path that includes "/l1/" or starts with the + # configured mount point. We grep for the function names + a path + # that suggests L1; precise enough to catch accidents and false- + # positive on legitimate writes to other paths is unlikely because + # most file-mutation calls are explicit about their target. + @l1_write_patterns [ + ~r/File\.write[!]?\s*\([^)]*l1\//, + ~r/File\.cp[!]?\s*\([^)]*l1\//, + ~r/File\.cp_r[!]?\s*\([^)]*l1\//, + ~r/File\.rm[!]?\s*\([^)]*l1\//, + ~r/File\.rm_rf[!]?\s*\([^)]*l1\//, + ~r/File\.rename[!]?\s*\([^)]*l1\//, + ~r/File\.touch[!]?\s*\([^)]*l1\//, + ~r/File\.mkdir[!]?\s*\([^)]*l1\//, + ~r/File\.mkdir_p[!]?\s*\([^)]*l1\//, + ~r/File\.open\s*\([^)]*l1\/.*\[[^\]]*:write/ + ] + + test "no Elixir module writes to the L1 mount" do + offenders = + for path <- source_files(), + text = File.read!(path), + pattern <- @l1_write_patterns, + match = Regex.scan(pattern, text), + match != [] do + {path, inspect(pattern)} + end + + assert offenders == [], ( + "L1 write detected in: #{inspect(offenders)}. The source is " <> + "external and inviolable (Devarim 4:2 lo tosif/lo tigra; " <> + "Vayikra 22:31 u'shmartem … va'asitem — keep and do, do not " <> + "author). L1 is read-only by architectural commitment. Mount " <> + "permissions defend at the filesystem layer; this CI invariant " <> + "defends in code so future contributors cannot bypass." + ) + end + + test "no Python module in korban_processor writes to L1" do + py_paths = + Path.wildcard("#{@korban_processor}/**/*.py") + |> Enum.reject(fn p -> String.contains?(p, "/test") end) + + py_l1_write_patterns = [ + ~r/open\s*\([^)]*l1\/[^)]*['"]w/, + ~r/Path\([^)]*l1\/[^)]*\)\.write/, + ~r/shutil\.(copy|move|rmtree)\s*\([^)]*l1\//, + ~r/os\.(remove|rename|mkdir)\s*\([^)]*l1\// + ] + + offenders = + for path <- py_paths, + text = File.read!(path), + pattern <- py_l1_write_patterns, + match = Regex.scan(pattern, text), + match != [] do + {path, inspect(pattern)} + end + + assert offenders == [] + end + + test "no Python module in azazel_processor writes to L1" do + py_paths = + Path.wildcard("#{@azazel_processor}/**/*.py") + |> Enum.reject(fn p -> String.contains?(p, "/test") end) + + offenders = + for path <- py_paths, + text = File.read!(path), + String.contains?(text, "l1/") and + (String.contains?(text, "open(") and String.contains?(text, "'w'")) do + path + end + + assert offenders == [] + end + + test "no Prolog module asserts into L1 facts" do + pl_paths = + Path.wildcard("../talmudic_engine/src/**/*.pl") + + # Prolog can't easily write to a filesystem; the relevant + # bypass shape is asserta/assertz to L1-shape predicates. + # The L1-shape predicates (verse/5, mitzvah/4, etc.) live in + # specification/ and are loaded as facts; assertions FROM + # outside specification/ that would mutate them is the + # architectural breach. + offenders = + for path <- pl_paths, + not String.contains?(path, "/specification/"), + not String.contains?(path, "/test/"), + text = File.read!(path), + Regex.match?(~r/assert[az]\s*\(\s*verse\s*\(/, text) or + Regex.match?(~r/assert[az]\s*\(\s*mitzvah\s*\(/, text) do + path + end + + assert offenders == [] + end +end diff --git a/vav_pipeline/test/step15_shema_test.exs b/vav_pipeline/test/step15_shema_test.exs index e8b19b82..7797f58a 100644 --- a/vav_pipeline/test/step15_shema_test.exs +++ b/vav_pipeline/test/step15_shema_test.exs @@ -294,6 +294,55 @@ defmodule Step15ShemaTest do # ============================================================ # Test 5: Context Immutability (Architecture §6.3) # ============================================================ + # ============================================================ + # Shema Test: Doorpost Inscription (vehaya §3.1, item 1) + # ============================================================ + # Devarim 11:18-19 — corporate inscription (v'samtem … al + # l'vavkhem) is the load-bearing input to threshold practice + # (b'shivt'kha b'beitekha). Every reception inscribes the + # corporate text on itself by carrying the Doorpost hash. + + describe "Shema doorpost inscription" do + test "ShemaContext carries the Doorpost expected_hash" do + {:ok, wednesday, _} = DateTime.from_iso8601(@wednesday_noon) + {:ok, context} = Shema.receive_context_at(@scope, wednesday) + + assert is_binary(context.doorpost_hash) + assert String.length(context.doorpost_hash) == 64 + assert context.doorpost_hash == VavPipeline.Doorpost.expected_hash() + end + + test "every reception bears the same corporate-text witness (the threshold inscribes the corporate text identically)" do + {:ok, wednesday, _} = DateTime.from_iso8601(@wednesday_noon) + + contexts = + for v <- [1, 2, 3] do + scope = %{book: "bereishit", chapter: 1, verse: v} + {:ok, ctx} = Shema.receive_context_at(scope, wednesday) + ctx.doorpost_hash + end + + # All three thresholds carry the SAME inscription — + # vehaya §3.3: "the threshold inscription is corporate. + # The threshold is singular but the inscription is not." + assert length(Enum.uniq(contexts)) == 1 + end + + test "the inscribed hash matches the documented spec set's identity" do + {:ok, wednesday, _} = DateTime.from_iso8601(@wednesday_noon) + {:ok, context} = Shema.receive_context_at(@scope, wednesday) + + # The threshold's witness IS the category's expected hash — + # making the load-bearing dependency explicit. If the spec + # set is in drift, the threshold inscribes the EXPECTED + # value (not the computed); operators detecting a mismatch + # at /kodesh/specification_identity know that all running + # thresholds are inscribing a now-out-of-sync hash and the + # category needs operator attention. + assert context.doorpost_hash == VavPipeline.Doorpost.expected_hash() + end + end + describe "Shema Test 5: Context Immutability" do test "ShemaContext is identical at every pipeline stage" do {:ok, wednesday, _} = DateTime.from_iso8601(@wednesday_noon)