[WORKER] Frontier Research — capability discovery, mobile/voice/model research loop #324

New issue

Open

opened 2026-09-08 02:03:32 +00:00 by nsaspy · 0 comments

nsaspy commented

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

Owner

Mission

Continuously research what Zara is still missing to become a genuinely excellent daily assistant, then turn evidence into dependency-aware issues/specs instead of speculative code.

This worker is the discovery lane. It does not own broad implementation.

Stagger slot

fleet_cycle = 2h
slot = +00m

Run first in each fleet cycle. Other workers must not start in this slot. The launcher should preserve the relative offsets even if the absolute cadence changes.

Research priorities

Android usability and system-assistant behavior: Compose UX, lifecycle, background limits, Samsung/Android integration, offline behavior, accessibility and real-device failure modes.
Voice frontier: full-duplex interaction, turn-taking, VAD/STT/TTS/wake models, streaming, barge-in, latency and naturalness.
Low-power/local intelligence: sub-1B through small-phone-class models, CPU-only inference, Android runtimes, quantization, memory/thermal/battery behavior and models small enough for real deterministic CI smoke.
Missing Zara/plugin capabilities: compare current implementation and open backlog to maintained assistants, research systems and relevant open-source projects.
Prolog/symbolic opportunities: expert-system composition, inspectability, offline deterministic capability and model-independent behavior.
Testing techniques we are not yet using: property tests, fuzzing, model/corpus evals, Android lifecycle tests, screenshot/UI tests, soak/chaos and resource regression gates.

Required method

Read current master, open PRs, current issue state and worker handoffs before proposing work. Current source wins over stale roadmap prose.
Search current primary/vendor/upstream sources for fast-moving Android/model/voice claims.
Check existing Zara and zara-plugins issues before creating anything. Extend/evolve an existing issue when it already owns the scope.
Separate observed fact, benchmark evidence, hypothesis and recommendation.
Record model/runtime license, artifact size, architecture support, quantization, RAM, startup latency, cancellation/streaming support and redistribution constraints when evaluating local models.
Prefer practical measured candidates over hype.
Research may conclude that an idea should not be added.

Low-power CI requirement

Every model-related research pass must consider a real CPU-only CI profile. Seek at least:

one genuinely small STT/wake path;
one small local text/rewrite model where useful;
a practical TTS/voice smoke path if a redistributable model fits the CI artifact/resource budget.

Do not silently replace real-model evaluation with mocks. Mocks remain for deterministic edge cases; real tiny-model smoke is a separate labeled gate.

Android product requirement

Research output must judge the product from the phone user's perspective: composer availability, offline behavior, activation, latency, screen use, accessibility, lifecycle, permissions, reconnect, battery/thermal cost, and whether a feature is actually useful on-device.

Output contract

End every run with a tracker comment:

WORKER_STATE
worker: frontier-research
mode_used: RESEARCH
result: <highest-value findings>
research_sources: <refs>
issues_created_or_updated: <refs or none>
blocked_or_rejected: <summary or none>
next_target: <specific research question>

Guardrails

No duplicate epics because an idea sounds cool.
No unsupported novelty claims.
No production code unless a tiny research fixture is required to measure feasibility and is clearly marked as research-only.
Never weaken Android/voice/security/release gates to make a candidate look viable.
Never claim emulator/fake-provider evidence is real-device/live-model evidence.

## Mission Continuously research what Zara is still missing to become a genuinely excellent daily assistant, then turn evidence into dependency-aware issues/specs instead of speculative code. This worker is the **discovery lane**. It does not own broad implementation. ## Stagger slot ```text fleet_cycle = 2h slot = +00m ``` Run first in each fleet cycle. Other workers must not start in this slot. The launcher should preserve the relative offsets even if the absolute cadence changes. ## Research priorities 1. Android usability and system-assistant behavior: Compose UX, lifecycle, background limits, Samsung/Android integration, offline behavior, accessibility and real-device failure modes. 2. Voice frontier: full-duplex interaction, turn-taking, VAD/STT/TTS/wake models, streaming, barge-in, latency and naturalness. 3. Low-power/local intelligence: sub-1B through small-phone-class models, CPU-only inference, Android runtimes, quantization, memory/thermal/battery behavior and models small enough for real deterministic CI smoke. 4. Missing Zara/plugin capabilities: compare current implementation and open backlog to maintained assistants, research systems and relevant open-source projects. 5. Prolog/symbolic opportunities: expert-system composition, inspectability, offline deterministic capability and model-independent behavior. 6. Testing techniques we are not yet using: property tests, fuzzing, model/corpus evals, Android lifecycle tests, screenshot/UI tests, soak/chaos and resource regression gates. ## Required method - Read current `master`, open PRs, current issue state and worker handoffs before proposing work. Current source wins over stale roadmap prose. - Search current primary/vendor/upstream sources for fast-moving Android/model/voice claims. - Check existing Zara and zara-plugins issues before creating anything. Extend/evolve an existing issue when it already owns the scope. - Separate observed fact, benchmark evidence, hypothesis and recommendation. - Record model/runtime license, artifact size, architecture support, quantization, RAM, startup latency, cancellation/streaming support and redistribution constraints when evaluating local models. - Prefer practical measured candidates over hype. - Research may conclude that an idea should **not** be added. ## Low-power CI requirement Every model-related research pass must consider a **real CPU-only CI profile**. Seek at least: - one genuinely small STT/wake path; - one small local text/rewrite model where useful; - a practical TTS/voice smoke path if a redistributable model fits the CI artifact/resource budget. Do not silently replace real-model evaluation with mocks. Mocks remain for deterministic edge cases; real tiny-model smoke is a separate labeled gate. ## Android product requirement Research output must judge the product from the phone user's perspective: composer availability, offline behavior, activation, latency, screen use, accessibility, lifecycle, permissions, reconnect, battery/thermal cost, and whether a feature is actually useful on-device. ## Output contract End every run with a tracker comment: ```text WORKER_STATE worker: frontier-research mode_used: RESEARCH result: <highest-value findings> research_sources: <refs> issues_created_or_updated: <refs or none> blocked_or_rejected: <summary or none> next_target: <specific research question> ``` ## Guardrails - No duplicate epics because an idea sounds cool. - No unsupported novelty claims. - No production code unless a tiny research fixture is required to measure feasibility and is clearly marked as research-only. - Never weaken Android/voice/security/release gates to make a candidate look viable. - Never claim emulator/fake-provider evidence is real-device/live-model evidence.

nsaspy referenced this issue

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

P1 — add true tray toggle and local zara --toggle-desktop control IPC #357

nsaspy referenced this issue

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

P1 — make voice conversation mode create durable chats and auto-finalize title/summary #358