P1 — add deterministic container lifecycle, readiness, persistence, restart, and upgrade integration gates #181

New issue

Open

opened 2026-08-22 21:57:58 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-22 21:57:58 +00:00

(Migrated from github.com)

Parent epic: #153
Depends on: #180

Goal

Prove the packaged image behaves as a real long-lived service artifact, not merely an archive that contains the right executable.

Required integration harness

Using Docker/Podman/OCI tooling available in CI or a deterministic archive-level fallback where privileged runtime is unavailable, exercise:

image load/inspect and exact zara-server entrypoint;
headless startup with no DISPLAY/Qt/audio device;
readiness/degraded/failure observability through a bounded non-secret interface;
clean SIGTERM/SIGINT shutdown and no orphan workers/sockets;
abrupt kill then clean restart/stale-lock recovery;
repeated restart loop;
persisted conversation/memory/security state volumes;
image upgrade across a checked fixture schema/state version;
failed migration leaves recoverable evidence and does not silently corrupt old state;
duplicate ownership/lock behavior within the selected container runtime model;
bounded startup/shutdown deadlines and logs.

Security assertions

Health/readiness checks expose no transcript, audio, secret key, provider credential or unnecessary principal identifiers. Release test fixtures use synthetic keys only and scan produced artifacts to prove those fixtures are not embedded in the image.

Gates

Tests first; one non-interactive scripts/test-zara-server-image.sh or equivalent authoritative command; Nix image build; full repo/Nix; exact-head Actions.

Acceptance

An immutable candidate image can be started, stopped, killed, restarted and upgraded against persistent volumes with deterministic lifecycle semantics and no secret-bearing health surface.

Parent epic: #153 Depends on: #180 ## Goal Prove the packaged image behaves as a real long-lived service artifact, not merely an archive that contains the right executable. ## Required integration harness Using Docker/Podman/OCI tooling available in CI or a deterministic archive-level fallback where privileged runtime is unavailable, exercise: - image load/inspect and exact `zara-server` entrypoint; - headless startup with no DISPLAY/Qt/audio device; - readiness/degraded/failure observability through a bounded non-secret interface; - clean SIGTERM/SIGINT shutdown and no orphan workers/sockets; - abrupt kill then clean restart/stale-lock recovery; - repeated restart loop; - persisted conversation/memory/security state volumes; - image upgrade across a checked fixture schema/state version; - failed migration leaves recoverable evidence and does not silently corrupt old state; - duplicate ownership/lock behavior within the selected container runtime model; - bounded startup/shutdown deadlines and logs. ## Security assertions Health/readiness checks expose no transcript, audio, secret key, provider credential or unnecessary principal identifiers. Release test fixtures use synthetic keys only and scan produced artifacts to prove those fixtures are not embedded in the image. ## Gates Tests first; one non-interactive `scripts/test-zara-server-image.sh` or equivalent authoritative command; Nix image build; full repo/Nix; exact-head Actions. ## Acceptance An immutable candidate image can be started, stopped, killed, restarted and upgraded against persistent volumes with deterministic lifecycle semantics and no secret-bearing health surface.