Jordan-Hall / Jordan-Hall/browser

[P0][CORE-03] Worker supervision and resource scheduler

Open
#4 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
0
Forks
0
PR merge metrics
No merged PRs in 30d

Description

Parent: #1

## Objective
Provide a Rust-owned supervisor for browser, connector, agent, inference, speech and desktop workers so failures or resource pressure cannot freeze the trusted UI or silently orphan authority.

## Scope
- Worker lifecycle: spawn, handshake, capability registration, health, restart, drain and terminate.
- Priority queues for deterministic UI/control, speech, foreground agents and background work.
- CPU/GPU/memory/concurrency budgets and per-task deadlines.
- Cancellation propagation and lease revocation.
- Backpressure between supervisor and workers.
- Crash-loop detection and degraded-mode operation.
- Resource telemetry needed for local-model scheduling.

## Design requirements
- Trusted shell remains responsive even when inference/browser/agent workers stall.
- Stop/cancel is a privileged fast path and is not queued behind model work.
- Workers receive only task-scoped state/capabilities.

## Acceptance criteria
- [ ] A stalled or OOM worker cannot prevent deterministic navigation or local stop acknowledgement.
- [ ] Crashed workers restart according to policy without duplicating externally significant work.
- [ ] CPU/GPU/memory budgets are observable and enforceable.
- [ ] Cancellation invalidates worker leases before any later dispatch.
- [ ] Priority inversion tests show control/speech responsiveness under heavy inference load.
- [ ] Crash loops enter a visible degraded state instead of infinite restart.

## Dependencies
- CORE-01
- CORE-02

**First phase:** P0
**Maturity target:** P3
**Workstream:** Runtime and contracts

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reading dependencies CORE-01 and CORE-02, then map the worker lifecycle and runtime contracts described in this issue. Use the acceptance criteria to define completion: responsive control paths, enforceable resource budgets, lease-invalidating cancellation, safe restart behavior, priority-inversion coverage, and visible degraded mode.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend, operating-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.