The Talmudic route ran only on a teiku from ki_tov, and ki_tov returns
teiku only for a root with no Hebrew — which the Shoresh Engine never
leaves. So the engine had never read a real question. Now every cycle
that resolves tov consults it with the roots it activated
(consult_engine/2, on the socket directly — never the client's stub;
an unreachable engine is reported "not consulted" and the cycle's
answer stands). A tamid probe does not consult.
The reading is said plainly (engine_reading_text/1): "Talmudic Engine
(resolved): 11 verse(s): Bereishit 1:1, …; 4 mitzvah/mitzvot:
know_hashem (1, positive), …" — the engine's own term form is no longer
pasted into a reader's answer. The verses join the sources as
references ("Bereishit 1:3", engine form beside), the L3 interpretation
carries them in torah_references with the reading in its reasoning and
processing_component "bereishit_cycle+talmudic_engine".
Proven against the engine running locally on its socket, bereishit 1:1
through VavPipeline.process/1: consulted :ok, 11 verses in the answer
and the sources, L3 torah_references 12; engine stopped → "not
consulted (Cannot connect)", answer stands, L3 component
bereishit_cycle; tamid probe → not consulted. Elixir 632/0.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
VavPipeline
TODO: Add description
Installation
If available in Hex, the package can be installed
by adding vav_pipeline to your list of dependencies in mix.exs:
def deps do
[
{:vav_pipeline, "~> 0.1.0"}
]
end
Documentation can be generated with ExDoc and published on HexDocs. Once published, the docs can be found at https://hexdocs.pm/vav_pipeline.