heaviness510/bikoret
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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>
This commit is contained in:
Scott KarpandClaude Fable 5.1 committed 2026-10-13 22:13:36 +00:00
1 parent b1c8358f8b
commit 017a9b89d4
22 files changed
+293 -251
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

KOHEN.md
+24 -24
View File
@@ -49,19 +49,19 @@ You inherit infrastructure that has been provisioned and verified:
| Resource | State |
|----------|-------|
| Exoscale SKS cluster `temple-council` | Running. 1× standard.medium node, 4 GB RAM, ~41% used. |
| PostgreSQL `temple-council-db` | Running. Database `shorashim` created. L3 migration applied. |
| Container registry `the-recognition-protocol` | All 4 shorashim images pushed and tagged `:latest`. |
| PostgreSQL `temple-council-db` | Running. Database `bikoret` created. L3 migration applied. |
| Container registry `the-recognition-protocol` | All 4 bikoret images pushed and tagged `:latest`. |
| Block Storage CSI driver | Installed. StorageClass `exoscale-sbs` available. |
| cert-manager + nginx-ingress | Running. ClusterIssuer `letsencrypt-prod` working. |
| Gitea (persistent storage) | Running. OAuth app + PAT exist for the operator's account. |
| Gitea MCP server | Running at `https://mcp.shorashim.ch`. Connected to claude.ai. |
| L1 Torah filesystem | In the `shorashim` repo at `l1/torah/`. SHA-256 `9e1abe4e…3c3086` (full hash in `l1/integrity.sha256`; verified at Day 1). |
| L1 Torah filesystem | In the `bikoret` repo at `l1/torah/`. SHA-256 `9e1abe4e…3c3086` (full hash in `l1/integrity.sha256`; verified at Day 1). |
| Image pull secret `shorashim-registry` | **Verify before assuming.** A prior partial setup may have created it. `kubectl get secrets -n shorashim` is the source of truth. |
| `shorashim-secrets` (DATABASE_URL) | **Verify before assuming.** Same as above. If present, also verify the role it points at (the architecture requires `shorashim_app`, not `avnadmin`). |
| `shorashim-config` ConfigMap | **Verify before assuming.** Runtime config (Shabbat lat/lng, paths, timeouts) — Construction §4.4. |
| L1 PersistentVolume in `shorashim` namespace | **NOT REQUIRED.** L1 is baked into each container image (~29MB). The `l1-volume.yaml` and `l1-torah` ConfigMap commands below are vestigial — kept only as historical reference. Do not apply them. |
| L1 PersistentVolume in `bikoret` namespace | **NOT REQUIRED.** L1 is baked into each container image (~29MB). The `l1-volume.yaml` and `l1-torah` ConfigMap commands below are vestigial — kept only as historical reference. Do not apply them. |
| Manna provision file | Not yet written — write at Day 4. |
| Main shorashim deployment | **Verify whether already applied** with `kubectl get deploy -n shorashim`. If pods exist but crashloop, check image architecture (see gate 0i). |
| Main bikoret deployment | **Verify whether already applied** with `kubectl get deploy -n shorashim`. If pods exist but crashloop, check image architecture (see gate 0i). |
**The aron is built. The garments are sewn. The cloud is visible. The kohen has not yet entered the tent.**
@@ -100,7 +100,7 @@ Each day validates one layer. Partial inauguration is no inauguration. If any da
Confirm L1 is in the repository and the integrity hash matches the firmware constant.
```bash
cd ~/shorashim # or wherever you cloned
cd ~/bikoret # or wherever you cloned
# 1. The scroll itself hashes to the constant baked into the binaries.
# (Until 2026-10-04 this step compared integrity.sha256 with the
@@ -140,7 +140,7 @@ exo dbaas user reveal-secrets temple-council-db avnadmin --zone ch-gva-2 -O json
Construct the URL (Ecto format with SSL):
```
ecto://avnadmin:<password>@temple-council-db-exoscale-66fffc16-59ac-4a62-9c19-f3fbe9c215d8.k.aivencloud.com:21699/shorashim
ecto://avnadmin:<password>@temple-council-db-exoscale-66fffc16-59ac-4a62-9c19-f3fbe9c215d8.k.aivencloud.com:21699/bikoret
```
#### 2b. Apply the secrets
@@ -151,7 +151,7 @@ export KUBECONFIG=~/.kube/exoscale-temple-council.yaml
# DATABASE_URL secret
kubectl create secret generic shorashim-secrets \
--namespace shorashim \
--from-literal=DATABASE_URL='ecto://avnadmin:<password>@…/shorashim'
--from-literal=DATABASE_URL='ecto://avnadmin:<password>@…/bikoret'
# Image pull secret for the private registry
kubectl create secret docker-registry shorashim-registry \
@@ -176,7 +176,7 @@ If a separate `shorashim_app` role does not exist yet, create it with restricted
```sql
CREATE ROLE shorashim_app WITH LOGIN PASSWORD '<strong-password>';
GRANT CONNECT ON DATABASE shorashim TO shorashim_app;
GRANT CONNECT ON DATABASE bikoret TO shorashim_app;
GRANT USAGE ON SCHEMA public TO shorashim_app;
GRANT SELECT, INSERT ON ALL TABLES IN SCHEMA public TO shorashim_app;
GRANT USAGE ON ALL SEQUENCES IN SCHEMA public TO shorashim_app;
@@ -267,7 +267,7 @@ engine" and served degraded. See the builder handoff-back.
```bash
# Confirm logs show the right startup messages
kubectl logs -n shorashim deploy/shorashim -c vav-pipeline | head -30
kubectl logs -n shorashim deploy/bikoret -c vav-pipeline | head -30
# Expect to see:
# Chatzotzrot: two silver trumpets ready
# AreiMiklat: cities of refuge ready
@@ -311,8 +311,8 @@ cat > /tmp/today.json <<EOF
EOF
# Find the pod and copy the file in
POD=$(kubectl get pod -n shorashim -l app.kubernetes.io/name=shorashim -o jsonpath='{.items[0].metadata.name}')
kubectl cp /tmp/today.json shorashim/$POD:/var/lib/shorashim/manna/today.json -c vav-pipeline
POD=$(kubectl get pod -n shorashim -l app.kubernetes.io/name=bikoret -o jsonpath='{.items[0].metadata.name}')
kubectl cp /tmp/today.json shorashim/$POD:/var/lib/bikoret/manna/today.json -c vav-pipeline
```
Verify:
@@ -325,7 +325,7 @@ curl -sk https://<your-domain>/kodesh/health | jq '.checks.manna_present'
If you have not yet pointed DNS at the LoadBalancer, use the cluster IP for now:
```bash
kubectl port-forward -n shorashim svc/shorashim 8080:80
kubectl port-forward -n shorashim svc/bikoret 8080:80
curl http://localhost:8080/kodesh/health | jq .
```
@@ -454,7 +454,7 @@ curl http://<host>/kodesh/status | jq '.manna_provision'
**24-hour observation period.** System runs but does not yet serve outside users. Watch logs:
```bash
kubectl logs -n shorashim deploy/shorashim -c vav-pipeline -f
kubectl logs -n shorashim deploy/bikoret -c vav-pipeline -f
```
---
@@ -563,32 +563,32 @@ the deployment, waits for 3/3, and takes two consecutive 200s from
re-admission lag). A new image must already be pushed as `:latest`. If
the day's manna has not been written, the new pod hangs at 2/3 until it
is (Day 4). `scripts/upstream-key-set` stores a caller's model key for
the gate scenario without echoing it (`~/.config/shorashim/upstream_keys`,
the gate scenario without echoing it (`~/.config/bikoret/upstream_keys`,
0600) — run it from a real terminal, not through a non-interactive runner.
### Standing at the gate — *Bishe'arecha*
A caller can put Shorashim between themselves and a model instead of
A caller can put Bikoret between themselves and a model instead of
bringing the output by hand: point the model's own client at the gate
and add the courtyard key. The request goes through unchanged under the
caller's own model key (never stored, never logged); the reply comes
back examined, with the fringe on its last text block, the headers
`X-Shorashim-Bedikah` / `X-Shorashim-Verdict`, and a `shorashim` object.
`X-Bikoret-Bedikah` / `X-Bikoret-Verdict`, and a `bikoret` object.
```bash
# Anthropic client: base_url = http://<host>/gate/anthropic, plus the courtyard key
curl -s -X POST http://<host>/gate/anthropic/v1/messages \
-H "Authorization: Bearer <courtyard key>" \
-H "x-api-key: <your Anthropic key>" -H "anthropic-version: 2023-06-01" \
-H "X-Shorashim-Rebuke: once" \
-H "X-Bikoret-Rebuke: once" \
-H "Content-Type: application/json" \
-d '{"model":"claude-sonnet-4-5","max_tokens":400,"messages":[{"role":"user","content":"..."}]}'
# OpenAI client: base_url = http://<host>/gate/openai/v1, the OpenAI key in Authorization,
# the courtyard key in X-Shorashim-Key
# the courtyard key in X-Bikoret-Key
```
`X-Shorashim-Rebuke: once` — a lo_tov reply is answered once more with
`X-Bikoret-Rebuke: once` — a lo_tov reply is answered once more with
the finding, and the second reply is delivered marked with both refs.
Each upstream call spends one `api_calls_external` of the day's manna
(Day 4): a provision with 0 shuts the gate (503 MANNA_DEPLETED) while
@@ -613,9 +613,9 @@ are, and the counts are engraved (never a specimen). From the machine
where the corpus lives:
```bash
cd ~/shorashim && PYTHONPATH=korban_processor/src python3 src/tools/hakhel.py # with the korban venv active \
cd ~/bikoret && PYTHONPATH=korban_processor/src python3 src/tools/hakhel.py # with the korban venv active \
--corpus <private>/specimens.jsonl --precision <private>/sample-precision-final.json \
--recall <private>/sample-recall.json --post http://<host> --key-file ~/.config/shorashim/api_keys
--recall <private>/sample-recall.json --post http://<host> --key-file ~/.config/bikoret/api_keys
curl -s http://<host>/peah/hakhel | jq '.readings[0] | {date, readings_ref, counts: .counts.any_stand}'
```
@@ -637,7 +637,7 @@ The halt monitor detected one of three cardinal sins:
```bash
# Inspect the halt
curl https://shorashim.ch/kodesh/status | jq .halt_status
kubectl logs -n shorashim deploy/shorashim -c vav-pipeline | grep HALT
kubectl logs -n shorashim deploy/bikoret -c vav-pipeline | grep HALT
# Investigate. Fix the root cause. Then resolve via the operator API.
# Resolution requires kohen authentication — never auto-resolve.
@@ -671,7 +671,7 @@ Three things are kept outside the mishkan repository, each for a Torah-grounded
| Repo / directory | Where | Why |
|---|---|---|
| `shorashim-readings` | `http://185.19.28.170:3000/heaviness510/shorashim-readings` | The book — Torah parshiyot read as AI specification. Companion to the mishkan. Lives beside the aron, not inside (Devarim 31:26). |
| `bikoret-readings` | `http://185.19.28.170:3000/heaviness510/shorashim-readings` | The book — Torah parshiyot read as AI specification. Companion to the mishkan. Lives beside the aron, not inside (Devarim 31:26). |
| `~/shorashim-source-data/morphhb` | local only | The quarry — raw WLC source. The carved tablets go in the aron; the quarry does not. |
| `~/shorashim-operator-notes` | local only / private | The kohen's runbook — environment-specific details, hostnames, account names. Private operator notes. Not part of the system's specification. |