- Augmented 2026-03-15-agent-platform-architecture.md with 6 missing sections: Teams Architecture, REST Route Specifications, /provider OAuth flow (URL+clipboard), preferences mutable migration, Test Strategy (per-task), and Phase Execution Order (wave plan) - Created spin-off plan stubs: gatekeeper-service.md, task-queue-unification.md, chroot-sandboxing.md - Added P8-007 through P8-019 to TASKS.md (13 new tasks) - Created Gitea issues #160-#172, Phase 8 milestone ms-165 - Updated MISSION-MANIFEST.md (Phase 8 in-progress) - Updated scratchpad with session 14 decisions Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2.7 KiB
2.7 KiB
Task Queue Unification — @mosaic/queue as Unified Orchestration Layer
Status: Stub — deferred. Referenced from
2026-03-15-agent-platform-architecture.md(Task Queue & Orchestration section). Implement after Workspaces (P8-015) is complete. Requires workspace file structure to be in place.
Date: 2026-03-15
Packages: packages/queue, packages/coord, packages/db, apps/gateway
Problem Statement
Two disconnected task systems exist:
@mosaic/coord— file-based missions (mission.json,TASKS.md), file locks, subprocess spawning. Single-machine orchestrator pattern.- PG tables (
tasks,mission_tasks,missions) — DB-backed CRUD, REST API, Brain repos.
An agent using coord_mission_status gets file data. The dashboard shows DB data. They are never in sync.
Vision
@mosaic/queue becomes the unified task orchestration service bridging PG, workspace files, and Valkey:
- DB is source of truth for structured state (status, assignees, timestamps)
- Workspace files (
TASKS.md, PRDs) are working copies for agent interaction - Valkey handles real-time assignment queues and agent claim locks
- Flatfile fallback for no-DB single-machine deployments (preserves
@mosaic/coordpattern)
Scope (To Be Designed)
@mosaic/queuerefactor — elevate from ioredis primitive to task orchestration service- DB ↔ file sync layer — writes to PG propagate to
TASKS.md; file edits by agents sync back - Task assignment queue — Valkey-backed RPUSH/BLPOP for agent task claiming
- Agent claim locks —
mosaic:queue:project:{id}:lock:{taskId}with TTL @mosaic/coordconsolidation — file-based ops ported into queue service;@mosaic/coordbecomes thin adapter or deprecated- Flatfile fallback — queue service writes JSON manifests when PG unavailable
- Status pub/sub — real-time task status updates via Valkey pub/sub
- Dependency resolution — block task assignment until dependencies are met
- Orchestrator monitor — gateway process watches task queue, assigns next based on dependency graph
- API surface — queue service exposes typed interface used by agents, gateway, and CLI
Dependencies
- Workspaces (P8-015) — file sync targets the workspace directory structure
- Teams architecture (P8-007) — project ownership determines queue namespacing
- DB schema stable — task/mission tables must not change mid-unification
References
- Original design context:
docs/plans/2026-03-15-agent-platform-architecture.md→ "Task Queue & Orchestration" section - Current
@mosaic/coordimplementation:packages/coord/src/ - Current
@mosaic/queueimplementation:packages/queue/src/