the name: Shorashim → Bikoret (בִּקֹּרֶת) — the specification

Vayikra 19:20 bikoret tihyeh — "there shall be an examination" — the one
noun Torah gives this function; its root ב-ק-ר is the priest's examining
of a mark by its signs (13:36) and the examining between good and bad
(27:33). The judges' form is v'darashta heitev … v'hineh emet nachon
hadavar / ed-sheker ha'ed (Devarim 13:15, 17:4, 19:18); the question
answered is eichah neda et hadavar asher lo dibro (18:21).

The system was named Shorashim ("roots") for the first thing built. Its
function became the examination of a model's output with the sources in
hand, and Torah re-cuts a name when the function is fixed, with its ki,
never for reach (Bereishit 2:19; 17:5; 32:29; 11:4). Nothing was changed
to fit the name; the root engine stays the pe'ah's reading cycle.

Spec files renamed bikoret_*.md; PRD §0 "The Name"; architecture §1.1;
README's Vayishlach row marked done; Tamid lists what still carries the
old word (Kubernetes resource names, the DB role, the domain, local
paths) and why, for the kohen's cut-over.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

KOHEN_PROMPT.md

@@ -1,6 +1,6 @@
 # Prompt for the Kohen Agent
 
-*Hand this to the kohen — human or AI — when shorashim is ready to be brought from built to serving. The detailed seven-day runbook is in `KOHEN.md`. This prompt puts you in role and points you at it.*
+*Hand this to the kohen — human or AI — when bikoret is ready to be brought from built to serving. The detailed seven-day runbook is in `KOHEN.md`. This prompt puts you in role and points you at it.*
 
 ---
 
@@ -73,15 +73,15 @@ kubectl get nodes
 exo dbaas show temple-council-db --zone ch-gva-2
 
 # 0c. Repo present at expected path
-test -d ~/shorashim/specs && test -d ~/shorashim/l1/torah && echo "repo OK"
+test -d ~/bikoret/specs && test -d ~/bikoret/l1/torah && echo "repo OK"
 
 # 0d. L1 integrity matches the firmware constant
-cd ~/shorashim
+cd ~/bikoret
 expected="9e1abe4edabac825d8a7037606ff247c3e8f8167650f04553f46c34e4f3c3086"
 python3 scripts/verify_l1.py l1 "$expected" || echo "L1 FAIL — STOP"
 
 # 0e. Specification identity (Doorpost)
-cd ~/shorashim/vav_pipeline
+cd ~/bikoret/vav_pipeline
 mix run -e 'IO.inspect VavPipeline.Doorpost.verify_identity()'
 # Expect: :ok
 # If {:error, ...}: a spec file has drifted. STOP. The builder, not you, addresses spec drift.
@@ -101,7 +101,7 @@ kubectl get pods -n cert-manager
 kubectl get pods -n ingress-nginx   # or traefik, whichever was installed
 
 # 0h. Namespace
-kubectl get ns shorashim || kubectl create ns shorashim
+kubectl get ns bikoret || kubectl create ns bikoret
 
 # 0i. Image architecture matches node architecture.
 #     Cluster nodes are linux/amd64. If the build was run on Apple Silicon
@@ -211,7 +211,7 @@ The halt monitor detected one of three cardinal sins:
 
 Procedure:
 1. `curl /kodesh/status | jq .halt_status` — read the halt cause
-2. `kubectl logs deploy/shorashim -c vav-pipeline | grep HALT` — read the firing event
+2. `kubectl logs deploy/bikoret -c vav-pipeline | grep HALT` — read the firing event
 3. Investigate root cause: recent inputs, recent deploys, recent config changes
 4. Resolve via the operator API **only after** root cause is understood and addressed
 5. Write an incident record (where the operator notes specify)