The workloads moved from the Pro SKS cluster (which cannot be
downgraded) to `temple-council-starter` on 2026-10-06. The manna claim
now names the static PV that carries the existing Exoscale volume
(Retain), so this manifest matches what is live and no longer points at
a class that deletes the volume with the claim.
gitea-mcp is pinned to the digest that is running. During the move the
old cluster restarted Gitea from `gitea/gitea:latest` and silently
upgraded it (1.27.1 → 28.0.0, database schema 343 → 356); a floating
tag on anything stateful is an upgrade waiting for the next restart.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Manna was an emptyDir: every pod creation emptied it and the vessel sat
unready until the kohen wrote the day's portion again. On 2026-10-04
that happened seven times in one day of rollouts. deploy/ARCHITECTURE.md
has always specified a block-storage volume for it and manna-volume.yaml
has always defined the claim; it was "not applied at Day 3" and stayed
that way.
- manna-volume.yaml: storageClassName exoscale-sbs (the cluster's only
class is not marked default — without it the claim stays Pending),
1Gi. Applied; bound in 6 s.
- deployment.yaml: the manna volume is the manna-pvc claim. `kubectl
diff` against the live deployment showed this as the only change.
- KOHEN.md: apply order (the claim before the pod), and the daily-ops
note — write once a day, not once per restart.
Verified on the live pod: manna written once onto the volume; then a
rollout restart with NO provision written by anyone — the new pod was
Ready and serving 49 s later, health 7/7, /peah/ask 200.
What this does not change: the portion still expires by its own date
and expires_at (Shemot 16:19-20). And the ledger is in memory — a
restarted pod counts consumption from zero against the same day's
allocation, as it always did; that is now reachable without the kohen's
hand, and is recorded as open.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
