# SJ2 Roadmap

This maps every feature from the Plus/Enterprise vision to a phase. "Built"
means it exists and runs in this repo today — you can `npm run build` and
exercise it. "Deferred" means it needs infrastructure this repo doesn't have
yet (a real frontend, a job queue, an audio pipeline, a hosted backend), and
is scoped honestly below rather than faked with placeholder UI.

## Phase 0 — Done in this pass

| Feature | Status | Where |
|---|---|---|
| Multi-agent orchestration (13 roles) | ✅ Built | `packages/agents` |
| Provider abstraction (9 providers + fallback) | ✅ Built | `packages/ai` |
| Model benchmarking (auto-select by quality/speed/cost/privacy) | ✅ Built | `packages/ai/src/benchmark.ts`, `sj2 plan --optimize-for` |
| Workflow builder (reusable pipelines, parallel execution) | ✅ Built | `packages/workflows`, `sj2 workflow run` |
| MCP client support | ✅ Built (minimal, real JSON-RPC) | `packages/mcp` |
| RBAC + audit logging | ✅ Built | `packages/auth` |
| SSO (generic OIDC client) | ✅ Built (needs a live IdP registration to run) | `packages/auth/src/sso.ts` |
| Plugin system + example plugin | ✅ Built | `packages/plugins`, `examples/plugins/docker` |
| Billing (NayaPay: payment-request + human-confirmed activation, entitlements) | ✅ Built (needs a real NayaPay account + admin auth wired up before production) | `packages/billing`, `apps/cloud` |
| Pricing tiers (Community/Sigma/Delta/Omega) | ✅ Built as data + enforcement | `packages/billing/src/plans.ts` |
| CLI (init/learn/plan/explain/implement/workflow/doctor) | ✅ Built | `apps/cli` |

## Phase 1 — Context & safety (next, per ARCHITECTURE.md §7)

- Context engine: relevant-file retrieval instead of full-architecture dumping
- `packages/filesystem` + `packages/git`: safe patch application, backups,
  checkpoints, rollback — unblocks `implement`/workflows actually writing code
- Dynamic agent selection in `Orchestrator` (currently a fixed 4-stage pipeline)
- Repository intelligence: dependency graph, technical debt scoring

## Phase 2 — Surface area

- `packages/api`: REST + GraphQL + WebSocket surface over `agents`/`workflows`/`billing`
- VS Code extension (sidebar, inline chat, review window, memory viewer)
- Web dashboard (Next.js) consuming the API package
- Git integration: AI commits, PR summaries, interactive staging

## Phase 3 — Team & enterprise depth

- Real DB-backed subscription store and audit log (Postgres) replacing the
  in-memory/JSON stand-ins in `apps/cloud` and `packages/auth`
- Organization knowledge graph (multi-project shared memory)
- Approval-chain enforcement wired into the orchestrator (the data model
  already exists in `packages/auth/src/rbac.ts` — `ApprovalChainPolicy`)
- CI/CD generation, deployment workflows, release notes/changelog generation

## Phase 4 — "Plus" ambitions — scoped honestly

These need real infrastructure this repo doesn't build in a CLI/library pass.
Each is listed with the concrete blocker, not just "later":

- **Background agents** (keep working while you're away): needs a durable job
  queue + worker process (e.g. BullMQ/Redis) and a way to resume a workflow
  mid-pipeline. `WorkflowEngine.run()` is already structured as resumable
  batches, so this is an execution-model change, not a rewrite.
- **Voice mode**: needs an audio capture/playback pipeline and a speech
  model integration — genuinely new surface area, not an extension of
  anything built here.
- **Visual architecture/dependency explorer**: needs the web dashboard
  (Phase 2) plus a real dependency-graph builder (`packages/indexer`, Phase 1)
  to have something worth visualizing.
- **Team analytics / repo health dashboards**: needs the dashboard (Phase 2)
  and enough real usage data (Phase 3's DB-backed history) to be meaningful
  rather than a chart of fake numbers.
- **Marketplace** (plugins, prompts, workflows, agents): needs hosting,
  review/moderation, and payment splitting — a cloud product surface, not a
  CLI feature. The plugin *loader* (Phase 0) is the local half of this; the
  marketplace is the distribution half.

## Guiding rule for every phase

Nothing above gets "shipped" as a UI shell with no logic behind it. If a
feature can't be built for real in a given pass, it stays in this roadmap as
a scoped, reasoned deferral — that's what "each release being polished and
genuinely useful" (your words) requires in practice.