Roadmap documents: distributed workers, MCP/plugin architecture, deployment path

Dshamir commits a series of planning documents laying out where the fork is heading: a 295-line candidate PRD for BullMQ worker offloading, an MCP server/client and plugin system design, local and cloud LLM provider support, and a Docker Compose to Kubernetes progression via k3s, Helm, and KEDA.

infrastructureintegration

None of this is code yet. What it gives you is the clearest window into architectural direction before the commits land.

The distributed-workers PRD proposes moving all long-running work off the backend container onto a BullMQ fleet backed by the Redis already present in the Compose stack. Three queues by latency class: pdf-ingest (CPU-bound), embeddings (mixed), llm-call (I/O-bound). Each would be a separate Compose service using the same Docker image as the backend, different entrypoint. Results write to Postgres; status updates push via SSE. The PRD gives measurable targets: p95 on /api/files below 300 ms under 50 concurrent OCR jobs, 200-page PDF analysis returning a { jobId } in under 500 ms instead of blocking for the full duration. The Celery worker pattern in Dshamir's own Exp_dental repo is cited as the precedent.

The MCP/plugin section describes making Mike both an MCP server (exposing documents, chat, workflows as tools at /mcp/) and an MCP client (connecting to external servers for credential vaults, legal databases, and enterprise connectors). Six proposed plugins are listed - knowledge base, custom agents, prompt templates, AI settings, a mission dashboard, and the distributed workers - each registering via a standardized interface with no core code changes required.

The deployment path sketches: Docker Compose today, then k3s on the same hardware as a bridge to Kubernetes APIs, then Helm charts for multi-node clusters, KEDA ScaledObjects for queue-depth autoscaling on worker pods, and Terraform for cloud provisioning. Each step is explicitly gated on the previous one - KEDA requires Helm and Distributed Workers Phase 3.

So what No code to import, but valuable context for deciding how much to track this fork. If the BullMQ worker and MCP server commits land as described, those would be worth evaluating on their own merits. The Redis client already present in the codebase is the substrate both proposals assume.

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

4 commits from Dshamir/AI-Legal, oldest first. Source extracted verbatim from the harvested git log.

SHA	Subject	Author	Date
`6207adcd`	Add candidate PRD: distributed CPU workers for AI-Legal	007	2026-05-23	↗ GitHub
commit body Goal-oriented proposal to move long-running and CPU-heavy work (PDF/OCR ingest, embeddings, LLM calls, report gen, notifications, cleanup) off the backend HTTP container onto a BullMQ-based worker fleet. Reuses existing Redis/Postgres/MinIO/GlitchTip substrate. Three phases: same-host workers, separate-host distribution, eventual KEDA autoscaling. Precedent: Exp_dental Celery worker pattern.
`5983a195`	docs: flesh out ROADMAP with categories, priorities, and distributed workers proposal	Dshamir	2026-05-23	↗ GitHub
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`1a6da718`	docs: add Plugin & MCP Architecture foundation and LLM compute providers to roadmap	Dshamir	2026-05-23	↗ GitHub
commit body Introduces the architectural direction for extensibility: - MCP Server (Mike as provider), MCP Client (consuming external services) - Plugin system with 6 proposed plugins from proposed-upgrades/ - Local LLM support (Ollama/vLLM) for air-gapped deployments - AWS GPU compute (Bedrock, SageMaker, EC2) for cloud burst Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`92120e2f`	docs: add deployment progression to roadmap (k3s, Helm, KEDA, Terraform)	Dshamir	2026-05-23	↗ GitHub
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

SHA

Subject

Author

Date

6207adcd

Add candidate PRD: distributed CPU workers for AI-Legal

007

2026-05-23

↗ GitHub

commit body

Goal-oriented proposal to move long-running and CPU-heavy work
(PDF/OCR ingest, embeddings, LLM calls, report gen, notifications,
cleanup) off the backend HTTP container onto a BullMQ-based
worker fleet. Reuses existing Redis/Postgres/MinIO/GlitchTip
substrate. Three phases: same-host workers, separate-host
distribution, eventual KEDA autoscaling. Precedent: Exp_dental
Celery worker pattern.

5983a195

docs: flesh out ROADMAP with categories, priorities, and distributed workers proposal

Dshamir

2026-05-23

↗ GitHub

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

1a6da718

docs: add Plugin & MCP Architecture foundation and LLM compute providers to roadmap

Dshamir

2026-05-23

↗ GitHub

commit body

Introduces the architectural direction for extensibility:
- MCP Server (Mike as provider), MCP Client (consuming external services)
- Plugin system with 6 proposed plugins from proposed-upgrades/
- Local LLM support (Ollama/vLLM) for air-gapped deployments
- AWS GPU compute (Bedrock, SageMaker, EC2) for cloud burst

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

92120e2f

docs: add deployment progression to roadmap (k3s, Helm, KEDA, Terraform)

Dshamir

2026-05-23

↗ GitHub

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-528.md from inside the repo you want the changes in.