Commit Graph
10 Commits
Author SHA1 Message Date
Scott KarpandClaude Opus 4.6 66686329ed Move operator notes out of repo, add generic architecture doc
memory/infrastructure.md and memory/build_log.md held environment-
specific details — hostnames, IPs, account names, credentials
retrieval commands, local kubeconfig paths, operational status
notes. These don't belong in a project repo; by convention they
live in private operator notes.

Moved to ~/shorashim-operator-notes/ (private, outside git).

In their place, added deploy/ARCHITECTURE.md — a generic
description of the deployment shape: components, external
dependencies, configuration surface. No hostnames. No IPs.
No account names. Any competent operator can read it and
know how to deploy shorashim to their own infrastructure.

Updated cross-references in AGENTS.md and BUILD_KORBAN.md to
point to "the operator's private notes" instead of memory/.

Project repo is spec + implementation + deployment shape.
Operator notes are the kohen's personal log.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-21 09:03:57 -04:00
Scott KarpandClaude Opus 4.6 324cf1a2ed Fix gitea-mcp env: use GITEA_ACCESS_TOKEN, not GITEA_TOKEN
The gitea-mcp server expects GITEA_ACCESS_TOKEN environment variable,
not GITEA_TOKEN. Without the correct env var, every API call to the
backend Gitea returns "token is required" — the MCP server can't
authenticate to fetch user info, repos, etc.

Also added GITEA_HOST env var as a backup to the --host flag.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-20 12:42:07 -04:00
Scott KarpandClaude Opus 4.6 42370bfc24 Fix MCP connector: cert-manager URL typo and TCP probes
Two fixes for the mcp.shorashim.ch deployment:
1. cert-manager ClusterIssuer had acme-v2 (wrong) instead of acme-v02
   (correct). Let's Encrypt ACME directory is at
   https://acme-v02.api.letsencrypt.org/directory
2. gitea-mcp HTTP probes timed out because GET /mcp hangs (SSE).
   Switched to TCP socket probes on port 8080.

MCP server now responds correctly over HTTPS at mcp.shorashim.ch:
  curl -X POST https://mcp.shorashim.ch/mcp -d '{...initialize...}'
  returns {"result":{"serverInfo":{"name":"Gitea MCP Server"}}}

Also: nginx-ingress configmap needed strict-validate-path-type=false
to allow cert-manager HTTP-01 challenges. Applied via kubectl patch,
not tracked in git manifests.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-17 14:53:30 -04:00
Scott KarpandClaude Opus 4.6 20e81114a5 Fix gitea-mcp deployment: add explicit command path
The gitea-mcp-server image has no entrypoint set (null).
Args were being interpreted as the executable name.
Added command: ["/app/gitea-mcp"] to invoke the binary correctly.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-16 22:21:13 -04:00
Scott KarpandClaude Opus 4.6 c7e0e6e703 Gitea MCP connector: K8s manifests for public claude.ai integration
Shemot 28:3 — v'asu et bigdei Aharon l'kadesho l'chahano li.
The garments connect the service to those who approach.

- gitea-mcp-deployment.yaml: Official gitea-mcp server in HTTP mode
  Connects to Gitea at 185.19.29.94 via PAT
- gitea-mcp-ingress.yaml: TLS ingress at mcp.shorashim.ch
  cert-manager auto-provisions Let's Encrypt certificate
- gitea-mcp-secret.yaml: Template for Gitea PAT (never committed with value)
- cert-manager-issuer.yaml: Let's Encrypt ClusterIssuer

Architecture: claude.ai → OAuth → mcp.shorashim.ch → Gitea API

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-16 14:02:45 -04:00
Scott KarpandClaude Opus 4.6 2f1205eef1 Bake L1 Torah into container images, simplify K8s deployment
L1 (29MB, 5860 files) is read-only and immutable — it belongs
inside the image, not on a separate volume. The scroll is sealed
in the aron. It ships with the vessel.

- All 4 Dockerfiles: COPY l1/ /mnt/torah/ in runtime stage
- deployment.yaml: Removed L1 PVC volume and all L1 volumeMounts
- deployment.yaml: Added imagePullSecrets for registry auth
- deployment.yaml: Manna uses emptyDir (kohen writes via kubectl cp)
- No CSI driver needed — eliminates Exoscale block storage dependency

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-01 13:16:31 -04:00
Scott KarpandClaude Opus 4.6 5e76c60218 Update K8s deployment with Exoscale container registry URLs
All 4 images now reference exo.container-registry.com/the-recognition-protocol/:
- vav-pipeline:latest (111MB)
- shoresh-engine:latest (128MB)
- talmudic-engine:latest (292MB)
- korban-processor:latest (187MB)

Images built and pushed. The garments are in the registry.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-30 21:24:15 -04:00
Scott KarpandClaude Opus 4.6 edb74da0b4 Fix shoresh engine Dockerfile: Debian Buster repos are EOL
haskell:9.6.4-slim is based on Debian Buster, which reached EOL.
The standard deb.debian.org repos return 404. Redirected to
archive.debian.org for zlib1g-dev installation.

Verified: shoresh-engine image builds successfully (128MB).

All 4 Docker images now build:
  vav-pipeline:      111MB
  shoresh-engine:    128MB
  korban-processor:  187MB
  talmudic-engine:   292MB

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-29 17:30:31 -04:00
Scott KarpandClaude Opus 4.6 f32e9afb03 Fix korban processor Dockerfile: pyswip 0.2.11 does not exist
pyswip 0.2.11 was never published to PyPI. Latest 0.2.x is 0.2.10.
Changed pin from ==0.2.11 to ==0.2.10.

Verified: korban-processor image builds successfully (187MB).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-29 17:25:23 -04:00
Scott KarpandClaude Opus 4.6 fe93c11d13 Phase 5 deployment: Dockerfiles, K8s manifests, halt monitor (Steps 33, 36)
Shemot 40:33 — Vay'khal Moshe et ham'lakhah.
The builder completes the work. The vessel is ready for transport.

Step 33 — Deployment configuration:
- Dockerfiles for all 4 components:
  - vav_pipeline: Elixir 1.16.1/OTP 26.2.1 release with Sanhedrin
  - shoresh_engine: GHC 9.6.4 binary
  - talmudic_engine: SWI-Prolog 9.2.2
  - korban_processor: Python 3.12.2 with pydantic
- Kubernetes manifests for Exoscale SKS (ch-gva-2):
  - Namespace, ConfigMap, Secrets template
  - L1 Torah PV/PVC (read-only mount)
  - Manna provision PVC (kohen writes, system reads)
  - Deployment: vav-pipeline + 3 sidecars, shared volumes
  - Service: ClusterIP + LoadBalancer with Exoscale NLB
  - Init container runs Ecto migrations (VavPipeline.Release)

Step 36 — Halt monitor (esh tamid):
- GenServer watches for three cardinal sins
- halt!/3 immediately halts system, sounds Chatzotzrot war signal
- Permanent audit log — halt events never deleted
- resolve/1 requires explicit operator action to resume
- alive?/0 for morning tamid verification
- 13 tests: alive check, 3 halt types, resolution, audit log,
  chatzotzrot war signal integration
- Added to supervision tree

All 219 Elixir + 19 L3 + 195 Prolog + 33 Haskell = 447+ tests, 0 failures

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-22 07:11:02 -04:00