[EPIC] Long-lived Zara daemon, ZeroMQ client protocol, multi-user isolation, and Voice replacement

lost-rob0t commented

2026-08-21 23:40:16 +00:00

(Migrated from github.com)

Goal

Turn Zara into a long-lived authenticated assistant service that can be started with zara --daemon and consumed by ordinary Zara clients over a versioned ZeroMQ protocol.

This is the architecture epic for making Zara usable as an owned/self-hosted replacement for the core day-to-day ChatGPT Voice workflow while preserving Zara's existing runtime, Prolog-first routing, actors, tools, memory, desktop, and voice roadmap.

RAGE research baseline

Research was completed first and committed on research/daemon-zeromq-voice-service:

docs/research/001-daemon-zeromq-voice-service.md

The research is grounded in the current Zara runtime plus ZeroMQ ROUTER/DEALER, ZMTP-CURVE/ZAP, PyZMQ socket controls, and current public ChatGPT Voice/Realtime behavior.

Required end state

zara --daemon starts one long-lived daemon with explicit startup/readiness/shutdown semantics.
ordinary Zara entry points can operate as clients of the daemon without importing or owning a second assistant runtime.
ZeroMQ is the canonical daemon transport.
the daemon uses asynchronous ROUTER and clients use DEALER.
application protocol v1 is explicitly versioned and documented independently of ZMTP.
binary audio is carried in multipart payload frames, not base64/JSON.
command/event types map onto Zara's existing runtime command/event vocabulary rather than creating a second domain model.
multiple authenticated users can connect concurrently.
conversations, context, memory, tool grants, events, quotas, and persistence are principal-scoped.
remote-capable TCP uses CURVE authentication/encryption plus ZAP principal mapping.
no payload-supplied user_id can override the authenticated principal.
authorization is enforced after authentication for daemon/runtime/tool/admin actions.
remote listening is opt-in and cannot become an unauthenticated public service by accident.
client-side microphone/playback becomes the target device boundary so remote/multi-user clients do not share one process-global audio device.
streaming STT, LLM text, phrase TTS, interruption/barge-in, cancellation, tool approvals, transcript/history, and memory work through the daemon connection.
reconnect preserves durable conversation state even when an in-flight audio turn cannot be resumed.
slow/malformed/malicious clients cannot create unbounded daemon memory growth or cross-user event leakage.
a release matrix proves multi-user isolation, authentication failure/revocation, frame limits, soak behavior, cancellation, and voice latency.

Protocol direction

Initial application framing after the ROUTER-owned routing identity:

"ZARA/1"
JSON envelope
0..N opaque payload frames

The v1 envelope carries typed message name, message/request id, session id, conversation/turn/stream correlation, sequence, timestamp, payload count, content type, and trace metadata. Authenticated principal identity is injected from transport/auth state and is not client-authoritative.

Initial message families include:

handshake/session: hello, hello.ok, session.resume, ping, pong, error;
conversation/runtime: conversation.open, turn.submit, turn.cancel, tool approvals, runtime status;
voice ingress: voice.start, audio.input.start/chunk/commit/cancel;
streamed egress: voice state, STT partial/final, assistant text delta/done, audio output start/chunk/done, tool lifecycle, turn completion/cancellation, runtime errors.

Architecture constraint

Do not wire the ZeroMQ gateway directly to AgentManager, Prolog, MemoryManager, TTS, or Qt widgets.

The daemon must extend the existing zara.runtime command/event boundary and existing TurnCoordinator semantics. Existing provider/model resources may be pooled only where they are stateless with respect to the user; conversations, context, memory, turn state, approvals, and private events require explicit principal ownership.

The existing zara.pets.ipc PUB/SUB bridge remains a compatibility transport and is not the new daemon protocol.

Security requirements

CURVE server key + unique client keypair for remote-capable sessions.
client pins daemon public key.
ZAP maps client public key -> Zara principal/roles.
key rotation/revocation.
owner-only secret-key files.
explicit ACL/capability checks at runtime command boundaries.
per-principal connection/rate/mailbox/model/tool/audio quotas.
bounded envelope and payload sizes plus ZeroMQ HWM/MAXMSGSIZE/timeouts/heartbeats.
no pickle/eval/dynamic class deserialization.
idempotency keys for retried side-effecting commands.
audit records contain IDs/action/result/timing but not transcript/audio/secrets.
cross-user memory/conversation/event isolation is a mandatory regression gate.

Voice replacement target

The minimum useful replacement is not just STT -> LLM -> TTS. It must provide a persistent live conversation with:

simultaneous/low-latency input and streamed output;
interruption/barge-in;
visible text alongside speech;
durable chat history;
per-user memory;
tools/search/approvals;
background daemon operation;
reconnect;
multi-user operation;
measurable latency and soak behavior.

Later extensions may add same-conversation images, Local Recall/screen context, video/media streaming, telephony, mobile clients, and offline profiles, but protocol v1 should not be blocked on video.

Dependencies / integration points

Reuse and integrate with existing work instead of duplicating it:

#51 context management
#82 runtime event contract
#83 RuntimeHost command bridge
#28 streamed LLM output
#29 phrase-sized streaming TTS
#30 warm startup
#31 full-duplex soak/release gate
#124 embedded Prolog LLM client
existing streaming STT/VAD, barge-in, acknowledgement, memory, tools, desktop, and Pet adapters

Dependency-ordered implementation slices

Child issues created from the RAGE research should cover:

daemon lifecycle/supervisor boundary;
ZARA/1 ZeroMQ wire protocol + client SDK + runtime bridge;
CURVE/ZAP auth, authorization, key lifecycle, quotas, and audit;
multi-user conversation/context/memory isolation;
streaming audio transport + client-owned devices + cross-process barge-in;
CLI/desktop daemon-client migration + reconnect/session UX;
Voice replacement release matrix + fuzz/soak/security/latency gates.

Non-goals

no Pykka/TurnCoordinator replacement just because ZeroMQ is used;
no second provider stack;
no second unrelated memory subsystem;
no unauthenticated public listener;
no Python-object/pickle wire format;
no global mutable current_user;
no desktop-only parallel protocol;
no requirement to complete video/screen streaming in v1;
no weakening of existing tool approval/capability policy.

Completion rule

This epic is complete only when the daemon/client path is the tested canonical service boundary for the supported client modes, multi-user privacy is regression-proven, voice interruption/latency gates pass, and the standalone fallback can be retained or removed based on measured parity rather than assumption.

## Goal Turn Zara into a long-lived authenticated assistant service that can be started with `zara --daemon` and consumed by ordinary Zara clients over a versioned ZeroMQ protocol. This is the architecture epic for making Zara usable as an owned/self-hosted replacement for the core day-to-day ChatGPT Voice workflow while preserving Zara's existing runtime, Prolog-first routing, actors, tools, memory, desktop, and voice roadmap. ## RAGE research baseline Research was completed first and committed on `research/daemon-zeromq-voice-service`: - `docs/research/001-daemon-zeromq-voice-service.md` The research is grounded in the current Zara runtime plus ZeroMQ ROUTER/DEALER, ZMTP-CURVE/ZAP, PyZMQ socket controls, and current public ChatGPT Voice/Realtime behavior. ## Required end state - [ ] `zara --daemon` starts one long-lived daemon with explicit startup/readiness/shutdown semantics. - [ ] ordinary Zara entry points can operate as clients of the daemon without importing or owning a second assistant runtime. - [ ] ZeroMQ is the canonical daemon transport. - [ ] the daemon uses asynchronous ROUTER and clients use DEALER. - [ ] application protocol v1 is explicitly versioned and documented independently of ZMTP. - [ ] binary audio is carried in multipart payload frames, not base64/JSON. - [ ] command/event types map onto Zara's existing runtime command/event vocabulary rather than creating a second domain model. - [ ] multiple authenticated users can connect concurrently. - [ ] conversations, context, memory, tool grants, events, quotas, and persistence are principal-scoped. - [ ] remote-capable TCP uses CURVE authentication/encryption plus ZAP principal mapping. - [ ] no payload-supplied `user_id` can override the authenticated principal. - [ ] authorization is enforced after authentication for daemon/runtime/tool/admin actions. - [ ] remote listening is opt-in and cannot become an unauthenticated public service by accident. - [ ] client-side microphone/playback becomes the target device boundary so remote/multi-user clients do not share one process-global audio device. - [ ] streaming STT, LLM text, phrase TTS, interruption/barge-in, cancellation, tool approvals, transcript/history, and memory work through the daemon connection. - [ ] reconnect preserves durable conversation state even when an in-flight audio turn cannot be resumed. - [ ] slow/malformed/malicious clients cannot create unbounded daemon memory growth or cross-user event leakage. - [ ] a release matrix proves multi-user isolation, authentication failure/revocation, frame limits, soak behavior, cancellation, and voice latency. ## Protocol direction Initial application framing after the ROUTER-owned routing identity: ```text "ZARA/1" JSON envelope 0..N opaque payload frames ``` The v1 envelope carries typed message name, message/request id, session id, conversation/turn/stream correlation, sequence, timestamp, payload count, content type, and trace metadata. Authenticated principal identity is injected from transport/auth state and is not client-authoritative. Initial message families include: - handshake/session: `hello`, `hello.ok`, `session.resume`, `ping`, `pong`, `error`; - conversation/runtime: `conversation.open`, `turn.submit`, `turn.cancel`, tool approvals, runtime status; - voice ingress: `voice.start`, `audio.input.start/chunk/commit/cancel`; - streamed egress: voice state, STT partial/final, assistant text delta/done, audio output start/chunk/done, tool lifecycle, turn completion/cancellation, runtime errors. ## Architecture constraint Do not wire the ZeroMQ gateway directly to AgentManager, Prolog, MemoryManager, TTS, or Qt widgets. The daemon must extend the existing `zara.runtime` command/event boundary and existing `TurnCoordinator` semantics. Existing provider/model resources may be pooled only where they are stateless with respect to the user; conversations, context, memory, turn state, approvals, and private events require explicit principal ownership. The existing `zara.pets.ipc` PUB/SUB bridge remains a compatibility transport and is not the new daemon protocol. ## Security requirements - CURVE server key + unique client keypair for remote-capable sessions. - client pins daemon public key. - ZAP maps client public key -> Zara principal/roles. - key rotation/revocation. - owner-only secret-key files. - explicit ACL/capability checks at runtime command boundaries. - per-principal connection/rate/mailbox/model/tool/audio quotas. - bounded envelope and payload sizes plus ZeroMQ HWM/MAXMSGSIZE/timeouts/heartbeats. - no pickle/eval/dynamic class deserialization. - idempotency keys for retried side-effecting commands. - audit records contain IDs/action/result/timing but not transcript/audio/secrets. - cross-user memory/conversation/event isolation is a mandatory regression gate. ## Voice replacement target The minimum useful replacement is not just STT -> LLM -> TTS. It must provide a persistent live conversation with: - simultaneous/low-latency input and streamed output; - interruption/barge-in; - visible text alongside speech; - durable chat history; - per-user memory; - tools/search/approvals; - background daemon operation; - reconnect; - multi-user operation; - measurable latency and soak behavior. Later extensions may add same-conversation images, Local Recall/screen context, video/media streaming, telephony, mobile clients, and offline profiles, but protocol v1 should not be blocked on video. ## Dependencies / integration points Reuse and integrate with existing work instead of duplicating it: - #51 context management - #82 runtime event contract - #83 RuntimeHost command bridge - #28 streamed LLM output - #29 phrase-sized streaming TTS - #30 warm startup - #31 full-duplex soak/release gate - #124 embedded Prolog LLM client - existing streaming STT/VAD, barge-in, acknowledgement, memory, tools, desktop, and Pet adapters ## Dependency-ordered implementation slices Child issues created from the RAGE research should cover: 1. daemon lifecycle/supervisor boundary; 2. `ZARA/1` ZeroMQ wire protocol + client SDK + runtime bridge; 3. CURVE/ZAP auth, authorization, key lifecycle, quotas, and audit; 4. multi-user conversation/context/memory isolation; 5. streaming audio transport + client-owned devices + cross-process barge-in; 6. CLI/desktop daemon-client migration + reconnect/session UX; 7. Voice replacement release matrix + fuzz/soak/security/latency gates. ## Non-goals - no Pykka/TurnCoordinator replacement just because ZeroMQ is used; - no second provider stack; - no second unrelated memory subsystem; - no unauthenticated public listener; - no Python-object/pickle wire format; - no global mutable `current_user`; - no desktop-only parallel protocol; - no requirement to complete video/screen streaming in v1; - no weakening of existing tool approval/capability policy. ## Completion rule This epic is complete only when the daemon/client path is the tested canonical service boundary for the supported client modes, multi-user privacy is regression-proven, voice interruption/latency gates pass, and the standalone fallback can be retained or removed based on measured parity rather than assumption.

lost-rob0t commented

2026-08-21 23:42:47 +00:00

(Migrated from github.com)

Dependency map from completed RAGE research

#128 daemon lifecycle / principal-aware supervisor
   |
   v
#129 ZARA/1 ROUTER/DEALER protocol + shared client SDK
   |
   v
#130 CURVE/ZAP auth + authorization + quotas/audit
   |
   v
#131 principal-scoped conversation/context/memory isolation
   | \
   |  +--------------------+
   v                       v
#132 live audio transport   #133 CLI/desktop daemon-client migration
   |                        ^
   +------------------------+
                |
                v
#134 Voice replacement + multi-user + fuzz/security/latency release gate

Created child issues:

#128 — long-lived zara --daemon lifecycle and supervisor
#129 — ZARA/1 wire protocol + reusable DEALER client
#130 — CURVE/ZAP auth, authorization, key lifecycle, abuse bounds
#131 — strict principal-scoped conversation/context/memory persistence
#132 — client-owned live audio transport and cross-process barge-in
#133 — CLI/desktop client migration, reconnect and session continuity
#134 — final Voice-replacement/security/fuzz/soak/latency gate

Research branch: research/daemon-zeromq-voice-service
Research doc: docs/research/001-daemon-zeromq-voice-service.md

Critical sequencing rule: do not expose remote multi-user operation as production-ready before #130 and #131 are complete and adversarially tested.

## Dependency map from completed RAGE research ```text #128 daemon lifecycle / principal-aware supervisor | v #129 ZARA/1 ROUTER/DEALER protocol + shared client SDK | v #130 CURVE/ZAP auth + authorization + quotas/audit | v #131 principal-scoped conversation/context/memory isolation | \ | +--------------------+ v v #132 live audio transport #133 CLI/desktop daemon-client migration | ^ +------------------------+ | v #134 Voice replacement + multi-user + fuzz/security/latency release gate ``` Created child issues: - #128 — long-lived `zara --daemon` lifecycle and supervisor - #129 — `ZARA/1` wire protocol + reusable DEALER client - #130 — CURVE/ZAP auth, authorization, key lifecycle, abuse bounds - #131 — strict principal-scoped conversation/context/memory persistence - #132 — client-owned live audio transport and cross-process barge-in - #133 — CLI/desktop client migration, reconnect and session continuity - #134 — final Voice-replacement/security/fuzz/soak/latency gate Research branch: `research/daemon-zeromq-voice-service` Research doc: `docs/research/001-daemon-zeromq-voice-service.md` Critical sequencing rule: do not expose remote multi-user operation as production-ready before #130 and #131 are complete and adversarially tested.

lost-rob0t commented

2026-08-22 05:10:41 +00:00

(Migrated from github.com)

RAGE iteration #139 has refined the executable boundary: zara remains the client name; zara-server is the canonical long-lived daemon/service executable. Older zara --daemon wording in this epic/research is superseded by that naming decision. #128 now establishes zara-server lifecycle plus a ZaraClient service abstraction; #129 will put the ZeroMQ DEALER implementation behind that client boundary.

RAGE iteration #139 has refined the executable boundary: **`zara` remains the client name; `zara-server` is the canonical long-lived daemon/service executable.** Older `zara --daemon` wording in this epic/research is superseded by that naming decision. #128 now establishes `zara-server` lifecycle plus a `ZaraClient` service abstraction; #129 will put the ZeroMQ DEALER implementation behind that client boundary.

lost-rob0t commented

2026-08-22 06:45:25 +00:00

(Migrated from github.com)

RAGE Iteration 1 / #128 is complete. PR #140 merged at 0a648c9157ec0f5dc63bc193acdc3b4fe1fcd4dc after exact-head CI #235 passed scripts/test-all.sh, nix flake check, nix build, and both Arch/Ubuntu shared-mic jobs. Shipped boundary: zara remains the client-facing command; zara-server owns long-lived foreground service lifecycle; ZaraClient is the transport-neutral seam; RuntimeSupervisor is principal-explicit; single-instance ownership uses an owner-private held lease. ZeroMQ transport/auth/hard multi-user isolation remain deliberately queued in #129-#131. Post-merge evidence PR #141 records the merge SHA in the append-only RAGE log.

RAGE Iteration 1 / #128 is complete. PR #140 merged at `0a648c9157ec0f5dc63bc193acdc3b4fe1fcd4dc` after exact-head CI #235 passed `scripts/test-all.sh`, `nix flake check`, `nix build`, and both Arch/Ubuntu shared-mic jobs. Shipped boundary: `zara` remains the client-facing command; `zara-server` owns long-lived foreground service lifecycle; `ZaraClient` is the transport-neutral seam; `RuntimeSupervisor` is principal-explicit; single-instance ownership uses an owner-private held lease. ZeroMQ transport/auth/hard multi-user isolation remain deliberately queued in #129-#131. Post-merge evidence PR #141 records the merge SHA in the append-only RAGE log.

lost-rob0t commented

2026-08-22 12:26:39 +00:00

(Migrated from github.com)

Daemon RAGE queue update: #129 is complete and merged via PR #142 (1cae2e32cc40112aa13af6b8f4b7319869c72bd9). Final exact-head authority was 3ab7d04c6af2e62f00570fb9ebdc731c4eb075c0, CI #284 fully green across full repo tests, flake check, packaged build, Arch shared-mic, and Ubuntu shared-mic.

Canonical boundary remains zara client / zara-server service. The next dependency-satisfied daemon slice is #130 (CURVE/ZAP authentication, authorization, key lifecycle, quotas/audit); #131 remains after it for hard principal isolation.

Daemon RAGE queue update: #129 is complete and merged via PR #142 (`1cae2e32cc40112aa13af6b8f4b7319869c72bd9`). Final exact-head authority was `3ab7d04c6af2e62f00570fb9ebdc731c4eb075c0`, CI #284 fully green across full repo tests, flake check, packaged build, Arch shared-mic, and Ubuntu shared-mic. Canonical boundary remains `zara` client / `zara-server` service. The next dependency-satisfied daemon slice is #130 (CURVE/ZAP authentication, authorization, key lifecycle, quotas/audit); #131 remains after it for hard principal isolation.

lost-rob0t commented

2026-08-22 18:41:23 +00:00

(Migrated from github.com)

#130 is complete. PR #145 merged at 71615bcd4cdece940db433cb79ea46fe9ad085e3 after exact-head CI #329 (32591012677) passed full regression, nix flake check, packaged Zara build, Arch shared-mic, and Ubuntu shared-mic on candidate fdf6f9a1d4e51a03ab4f46b1f291cf262e416020. The final coverage pass also added a red-first regression proving unmapped daemon actions fail closed instead of inheriting session.basic. Next dependency-satisfied daemon child is #131; do not begin it in this completed RAGE iteration.

#130 is complete. PR #145 merged at `71615bcd4cdece940db433cb79ea46fe9ad085e3` after exact-head CI #329 (`32591012677`) passed full regression, `nix flake check`, packaged Zara build, Arch shared-mic, and Ubuntu shared-mic on candidate `fdf6f9a1d4e51a03ab4f46b1f291cf262e416020`. The final coverage pass also added a red-first regression proving unmapped daemon actions fail closed instead of inheriting `session.basic`. Next dependency-satisfied daemon child is #131; do not begin it in this completed RAGE iteration.

lost-rob0t commented

2026-08-22 23:27:39 +00:00

(Migrated from github.com)

RAGE child #131 is complete. PR #148 merged at 1a076e9921228d9d0eb18ea63225a1862f81023d after exact-head CI #372 passed the full repository/Nix/package/shared-mic gate. #131 is closed completed. Per the epic ordering, #132 is now the next dependency-satisfied daemon slice, but it will be consumed only in a later RAGE iteration after a fresh queue read.

RAGE child #131 is complete. PR #148 merged at `1a076e9921228d9d0eb18ea63225a1862f81023d` after exact-head CI #372 passed the full repository/Nix/package/shared-mic gate. #131 is closed completed. Per the epic ordering, #132 is now the next dependency-satisfied daemon slice, but it will be consumed only in a later RAGE iteration after a fresh queue read.

lost-rob0t commented

2026-08-23 16:10:28 +00:00

(Migrated from github.com)

Daemon RAGE status update: #132 completed and merged via PR #185 at 4c6018b30ff4be2e168551f0cf256f8333bc58af. Exact implementation head 06f23ede1120d482dfa6b28c1168adf7c335951f passed CI #449 including full repository tests, nix flake check, packaged Zara build, and both Arch/Ubuntu shared-mic probes. #133 is now the next daemon child eligible for fresh consumption in a later RAGE iteration; #134 remains the final release proof gate.

Daemon RAGE status update: #132 completed and merged via PR #185 at `4c6018b30ff4be2e168551f0cf256f8333bc58af`. Exact implementation head `06f23ede1120d482dfa6b28c1168adf7c335951f` passed CI #449 including full repository tests, `nix flake check`, packaged Zara build, and both Arch/Ubuntu shared-mic probes. #133 is now the next daemon child eligible for fresh consumption in a later RAGE iteration; #134 remains the final release proof gate.

lost-rob0t commented

2026-08-24 02:11:09 +00:00

(Migrated from github.com)

RAGE #133 is complete. PR #188 merged at 487996d56467f5227c5c6b1178333fbf1ee6d8a0 after exact-head CI #484 passed the full repository tests, nix flake check, packaged build, and both Arch/Ubuntu shared-mic gates. Issue #133 closed as completed.

Daemon queue status: #128-#133 are complete; #134 is now dependency-satisfied and remains the next child by declared order, to be consumed only in a later RAGE iteration.

ADADR control-plane discovery before that next architecture slice found Zara actively uses the canonical AGENTS.md + skills/rage/SKILL.md + append-only rage/ workflow, but no durable repository instruction selects human-gated ADADR vs Auto-RAGE. Do not silently assume Auto-RAGE for #134; select and persist the mode before its architecture work begins.

Permanent naming remains zara client / zara-server daemon; no Prolog-RLM path.

RAGE #133 is complete. PR #188 merged at `487996d56467f5227c5c6b1178333fbf1ee6d8a0` after exact-head CI #484 passed the full repository tests, `nix flake check`, packaged build, and both Arch/Ubuntu shared-mic gates. Issue #133 closed as completed. Daemon queue status: #128-#133 are complete; #134 is now dependency-satisfied and remains the next child by declared order, to be consumed only in a later RAGE iteration. ADADR control-plane discovery before that next architecture slice found Zara actively uses the canonical `AGENTS.md` + `skills/rage/SKILL.md` + append-only `rage/` workflow, but no durable repository instruction selects human-gated ADADR vs Auto-RAGE. Do not silently assume Auto-RAGE for #134; select and persist the mode before its architecture work begins. Permanent naming remains `zara` client / `zara-server` daemon; no Prolog-RLM path.

lost-rob0t commented

2026-08-24 04:57:40 +00:00

(Migrated from github.com)

RAGE #134 reconciliation (2026-08-24): final release realization was rejected by Auto-RAGE after acceptance-level research disproved readiness.

#132 is reopened because its stated partial/final transcript-over-ZARA/1 acceptance is not implemented by the current RuntimeVoiceIngress / protocol event path.
#191 now owns the missing current-daemon tool lifecycle + explicit approval interaction through authenticated ZaraClient / ZARA/1.
Required voice/provider work remains with the existing #17 -> #28 -> #29 -> #30 -> #31 chain. #134 will compose/prove those contracts; it will not duplicate them.
PR #190 remains draft/unmerged and standalone remains retained. No daemon-default/canonicality claim is authorized.

Research/design/decision evidence is append-only under PR #190 in rage/134-daemon-release-{research,design,gate}.org.

RAGE #134 reconciliation (2026-08-24): final release realization was rejected by Auto-RAGE after acceptance-level research disproved readiness. - #132 is reopened because its stated partial/final transcript-over-ZARA/1 acceptance is not implemented by the current `RuntimeVoiceIngress` / protocol event path. - #191 now owns the missing current-daemon tool lifecycle + explicit approval interaction through authenticated `ZaraClient` / ZARA/1. - Required voice/provider work remains with the existing #17 -> #28 -> #29 -> #30 -> #31 chain. #134 will compose/prove those contracts; it will not duplicate them. - PR #190 remains draft/unmerged and standalone remains retained. No daemon-default/canonicality claim is authorized. Research/design/decision evidence is append-only under PR #190 in `rage/134-daemon-release-{research,design,gate}.org`.

nsaspy referenced this issue

2026-08-28 03:31:13 +00:00

docs: research Zara daemon and ZeroMQ voice service #135

nsaspy referenced this issue

2026-08-28 03:31:14 +00:00

feat: establish zara-server lifecycle boundary via RAGE #140

nsaspy referenced this issue

2026-08-28 03:31:14 +00:00

RAGE #129: implement ZARA/1 protocol and ZeroMQ client #142

nsaspy referenced this issue

2026-08-28 03:31:15 +00:00

RAGE #130: CURVE/ZAP authentication and daemon security controls #144

nsaspy referenced this issue

2026-08-28 03:31:15 +00:00

RAGE #131: principal-scope conversations and memory #147

nsaspy referenced this issue

2026-08-28 03:31:15 +00:00

RAGE #131: principal-scoped conversation and memory isolation #148

nsaspy referenced this issue

2026-08-28 03:31:16 +00:00

RAGE #132: live voice over ZARA/1 #185

nsaspy referenced this issue

2026-08-28 03:31:16 +00:00

RAGE #133: migrate CLI and desktop onto ZaraClient #188

nsaspy referenced this issue

2026-08-28 03:31:17 +00:00

RAGE #134: daemon release gate #190

nsaspy referenced this issue

2026-08-28 03:31:17 +00:00

RAGE #132: restore client-visible streaming STT events #192

nsaspy referenced this issue

2026-08-29 10:40:44 +00:00

[ORDER] ZARA-000 — Repository repair and real-time voice roadmap #1

nsaspy referenced this issue

2026-09-02 17:27:43 +00:00

P1 — migrate the zara wake listener onto the daemon ZARA/1 voice client with principal-scoped memory #227

nsaspy referenced this issue

2026-09-04 14:39:03 +00:00

TASK: implement first-class Zara daemon via RAGE #139

nsaspy referenced this issue

2026-09-04 22:52:37 +00:00

Make Zara CLI use daemon-owned timers by default #296

nsaspy referenced this issue

2026-09-05 01:34:44 +00:00

P1 — migrate CLI and desktop surfaces onto the daemon client with reconnect and session continuity #133

nsaspy referenced this issue

2026-09-08 02:03:34 +00:00

[EPIC] Model-independent Zara identity and graceful intelligence degradation #336

nsaspy referenced this issue

2026-09-08 02:03:35 +00:00

[EPIC] Zara Cognitive Kernel — intent OS, frontier voice parity, and verifiable autonomy #345

nsaspy referenced this issue

2026-09-08 02:03:38 +00:00

P0 regression — production zara-server must expose opt-in authenticated CURVE/ZAP listener for Android #173 #355

nsaspy commented

2026-09-08 02:07:54 +00:00

Owner

Dependency reconciliation — 2026-09-07

The daemon architecture remains active and must stay open, but one dependency reference in this body is stale:

#124 is closed/not planned; merged PR #233 replaced that embedded-client design with the pinned bounded Prolog-RLM direct-mode rewrite path now hardened by #122.
#131, #132 and #133 are now closed/completed; their contracts are part of the current daemon baseline rather than future assumptions.

Do not revive #124 just to satisfy this old dependency list. For model-backed pre-semantic rewriting, use current #122/#233. The daemon's actual remaining release claim still depends on unfinished parity/proof work such as #29/#30/#31 and #134, so this epic is not superseded by #624 and is not safe to close.

## Dependency reconciliation — 2026-09-07 The daemon architecture remains active and **must stay open**, but one dependency reference in this body is stale: - #124 is closed/not planned; merged PR #233 replaced that embedded-client design with the pinned bounded Prolog-RLM direct-mode rewrite path now hardened by #122. - #131, #132 and #133 are now closed/completed; their contracts are part of the current daemon baseline rather than future assumptions. Do not revive #124 just to satisfy this old dependency list. For model-backed pre-semantic rewriting, use current #122/#233. The daemon's actual remaining release claim still depends on unfinished parity/proof work such as #29/#30/#31 and #134, so this epic is **not** superseded by #624 and is not safe to close.

Rows
Columns

[EPIC] Long-lived Zara daemon, ZeroMQ client protocol, multi-user isolation, and Voice replacement #127

Goal

RAGE research baseline

Required end state

Protocol direction

Architecture constraint

Security requirements

Voice replacement target

Dependencies / integration points

Dependency-ordered implementation slices

Non-goals

Completion rule

Dependency map from completed RAGE research

Dependency reconciliation — 2026-09-07