crumb-missions-core · Deploy auf einen Zero

Der reproduzierbare Weg, wie crumb-missions-core auf einen Pi Zero
(aarch64, Debian 12, ~416 MB RAM) kommt und dort reboot-fest lÀuft. Der Zero
kann Rust nicht selbst kompilieren — also Cross-Build woanders, dann Binary
rĂŒber.

1. aarch64-Cross-Build (auf einem Apple-Silicon-Mac, nativer arm64-Container)

docker run --rm --platform linux/arm64 \
  -e CARGO_TARGET_DIR=/work/target-linux-arm64 \
  -v "$PWD":/work -w /work \
  rust:1-bookworm cargo build --release
# -> target-linux-arm64/release/crumb-missions  (~1.1 MB, stripped, glibc)

rust:1-bookworm matcht die Debian-12-glibc des Ziels. Eigenes
CARGO_TARGET_DIR, damit der Linux-Build nicht mit einem lokalen
macOS-target/ kollidiert.

2. Binary auf den Zero

scp target-linux-arm64/release/crumb-missions sysop@<zero>:/home/sysop/crumb-missions

Die missions/ liegen bereits im Klon ~/Crumbmissions auf dem Zero (der
Binary braucht sie zur Laufzeit via CRUMB_MISSIONS_ROOT).

3. Reboot-feste Unit

scp deploy/crumb-missions.service sysop@<zero>:/home/sysop/
ssh sysop@<zero> '
  sudo cp /home/sysop/crumb-missions.service /etc/systemd/system/
  sudo systemctl daemon-reload
  sudo systemctl enable --now crumb-missions
'

PrĂŒfen: systemctl is-enabled crumb-missions → enabled (startet beim Boot),
curl -s http://127.0.0.1:8791/health → ok.

Was der Dienst ist — und was nicht

  • Der Dienst fĂ€hrt nur serve: read-only GET /api/missions + /health
    auf 127.0.0.1. ~2,6 MB RSS.
  • Der Runner (crumb-missions run <kat> <name>) lĂ€uft nicht als
    Dienst. Eine Mission auszufĂŒhren ist die gegatete CKL-Grenze, die der KrĂŒmel
    bewusst im eigenen Terminal auslöst — nicht ein Hintergrunddienst.

Zwei Achsen auf einem Zero

Derselbe Zero trÀgt beide Rust-Achsen des Waldes:

  • Inferenz — rag in CrumbQuestions_v0 (dĂŒnner Client zum Hub: Qdrant/Ollama)
  • Zustand/Handlung — crumb-missions-core (Katalog · API · gegateter Runner, lokal)

Ort des Denkens ≠ Ort des Handelns, und beides darf klein sein.