[Zara reuse][BLOCKED] Extract frontend-safe scheduled task query/control contract from Zara #383

New issue

Open

opened 2026-09-08 01:29:17 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-08 01:29:17 +00:00

Owner

Downstream proving ground: lost-rob0t/zara#654
Design/architecture epic: lost-rob0t/zara#648
Design freeze: lost-rob0t/zara#649

Why this exists

Zara Android is implementing a Scheduled surface that lists and inspects upcoming/active/completed/failed long-horizon work and exposes authorized pause/resume/cancel/create/edit controls over Zara's canonical task runtime.

Do not create a new scheduler in Prolog-RLM for this issue. This is an extraction/reuse task and is intentionally blocked until Zara #654 has executable behavior and tests proving the frontend contract.

Prolog-RLM already has canonical async scheduling/runtime machinery; the missing reusable seam is a bounded frontend-safe task projection/control protocol, if Zara's implementation proves it is genuinely generic.

Extraction target after Zara proves it

Potential domain-neutral pieces to extract:

stable opaque task identity;
schedule/cadence + next-run/last-run projection;
lifecycle states such as upcoming/running/completed/failed/paused/cancelled/degraded;
bounded result/evidence references;
explicit ownership/location metadata when local/remote distinction is meaningful;
correlated authorized control commands for pause/resume/cancel;
idempotency/reconciliation semantics for repeated controls;
structured errors and stale/degraded state;
frontend protocol extension/facade integration where appropriate.

Exact schema and command names must come from the Zara implementation, not this issue text.

Required linkage before implementation starts

A worker must first link:

Zara #654 implementation PR/commit;
Zara task projection/control adapter;
RED-first tests/fixtures including cancellation/idempotency;
a Zara-specific vs generic seam table.

Until then, this remains blocked.

Invariants

reuse the existing canonical scheduler/async machinery; no second scheduler;
availability does not imply authority;
pause/resume/cancel must use explicit correlated commands and capability checks;
task state is bounded; no frontend reconstruction from logs;
repeated reconnect/control cannot duplicate execution;
no Android UI/product policy enters Prolog-RLM.

Acceptance

Zara #654 executable implementation/tests are linked first;
extracted contract composes with the existing canonical scheduler rather than replacing it;
stable task identity/lifecycle/control semantics have deterministic tests;
authority, idempotency and cancellation races are covered;
protocol compatibility/versioning is explicit;
Zara can consume the reusable contract after extraction;
no Zara-specific visual/product policy moves upstream.

Downstream proving ground: `lost-rob0t/zara#654` Design/architecture epic: `lost-rob0t/zara#648` Design freeze: `lost-rob0t/zara#649` ## Why this exists Zara Android is implementing a Scheduled surface that lists and inspects upcoming/active/completed/failed long-horizon work and exposes authorized pause/resume/cancel/create/edit controls over Zara's canonical task runtime. **Do not create a new scheduler in Prolog-RLM for this issue.** This is an extraction/reuse task and is intentionally blocked until Zara #654 has executable behavior and tests proving the frontend contract. Prolog-RLM already has canonical async scheduling/runtime machinery; the missing reusable seam is a bounded frontend-safe *task projection/control protocol*, if Zara's implementation proves it is genuinely generic. ## Extraction target after Zara proves it Potential domain-neutral pieces to extract: - stable opaque task identity; - schedule/cadence + next-run/last-run projection; - lifecycle states such as upcoming/running/completed/failed/paused/cancelled/degraded; - bounded result/evidence references; - explicit ownership/location metadata when local/remote distinction is meaningful; - correlated authorized control commands for pause/resume/cancel; - idempotency/reconciliation semantics for repeated controls; - structured errors and stale/degraded state; - frontend protocol extension/facade integration where appropriate. Exact schema and command names must come from the Zara implementation, not this issue text. ## Required linkage before implementation starts A worker must first link: 1. Zara #654 implementation PR/commit; 2. Zara task projection/control adapter; 3. RED-first tests/fixtures including cancellation/idempotency; 4. a `Zara-specific` vs `generic` seam table. Until then, this remains blocked. ## Invariants - reuse the existing canonical scheduler/async machinery; no second scheduler; - availability does not imply authority; - pause/resume/cancel must use explicit correlated commands and capability checks; - task state is bounded; no frontend reconstruction from logs; - repeated reconnect/control cannot duplicate execution; - no Android UI/product policy enters Prolog-RLM. ## Acceptance - [ ] Zara #654 executable implementation/tests are linked first; - [ ] extracted contract composes with the existing canonical scheduler rather than replacing it; - [ ] stable task identity/lifecycle/control semantics have deterministic tests; - [ ] authority, idempotency and cancellation races are covered; - [ ] protocol compatibility/versioning is explicit; - [ ] Zara can consume the reusable contract after extraction; - [ ] no Zara-specific visual/product policy moves upstream.

nsaspy referenced this issue

2026-09-08 01:29:20 +00:00

[EPIC][experts] Closed-loop integration: Requirement→Knowledge→Plan→Experts→VERIFY→Repair→Review→completion #411

nsaspy referenced this issue

2026-09-08 01:29:21 +00:00

[EPIC][expert] Review / critic expert: adversarial change analysis, regression discovery, and evidence-backed findings #412

nsaspy referenced this issue

2026-09-08 01:29:21 +00:00

[EPIC][expert] Repair / diagnosis expert: failure hypotheses, evidence gaps, bounded repair, and no-progress detection #413

nsaspy referenced this issue

2026-09-08 01:46:19 +00:00

[EPIC][P0] First-class Prolog expert system: registry, routing, specialists, and closed-loop Spec→Plan→Expert→Verify→Repair #422