core/ROADMAP.md

Switchboard Core — Roadmap

Current: v0.1.0 — The Kernel

Fork of chat-switchboard, gutted to a pure extension platform. All AI/chat features removed from the kernel. What remains is the minimum viable platform that extensions build on.

Retained kernel capabilities

• Auth: builtin (simple), mTLS, OIDC
• Identity: users, teams, groups, permissions (RBAC)
• Packages: surfaces, extensions, libraries, workflows
• Starlark sandbox: capability-gated modules
• Storage: object storage (PVC, S3), ext_data tables
• Realtime: WebSocket hub, presence, multi-replica HA
• Ops: audit log, notifications, maintenance goroutine

Phase 0 (in progress)

Step	Status	Description
1. Module rename	✅	chat-switchboard → switchboard-core
2. Delete packages	✅	15 Go packages, 29 handler files removed
3. Gut stores/models	✅	40 → 20 store interfaces, kernel-only models
4. Fresh migrations	✅	9 files × 2 dialects, 27 tables
5. Fix compilation	✅	go build ./... clean, 300+ stale route lines cut
6. Fix tests	✅	8 test packages pass, ~12K stale test lines pruned
7. Frontend gut	✅	Shell + SDK only, 50+ files of chat/notes/projects code removed
8. New ICD	🔧	Stub in place, full kernel-only spec TBD
9. CI/CD + Dockerfile	✅	Single unified image, FE/BE split removed, DB names updated, k8s var alignment fixes (resource quantities, image name, rollout deployment name)
10. Smoke test + tag	🔧	Deploy passes CI, verify health + ingress routing, tag v0.1.0

v0.2.0 — SDK & Triggers

The contract that extensions build against. Three trigger primitives, SDK stabilization, and the first rebuilt extension (tasks).

• Trigger system: time (cron), webhook (inbound HTTP), event (bus subscription)
• Event bus subscriptions: extensions register match expressions at install time
• SDK contract: sb.slots(), sb.actions, sb.api.ext(), sb.storage
• Primitive UI components: toast, confirm, prompt, dialog (stabilize existing)
• Theme tokens exposed to extensions
• Task extension: first proof-of-concept — full task system rebuilt as a Starlark extension using triggers + ext_data + notifications
• Settings override model: RBAC controls scope auth (admin → global, team-admin → team, user → personal). user_overridable flag on each setting controls whether lower scopes can override higher. Resolution order: user → team → global (first non-null wins, walking up if overridable). Extension manifests declare user_overridable per setting key.
• Default surface routing: / redirects to configurable default surface. No surfaces installed → admin surface is default. First surface installed becomes default. Changeable in admin settings.

v0.3.0 — Editor Surface

The code/markdown editor rebuilt as an installable surface package. Zero platform special-casing. Proves the full extension stack E2E.

• Editor as .pkg archive
• CM6 integration via surface viewport
• File tree, tabs, preview pane — all extension-provided

v0.4.0 — Chat Extension

The AI chat system rebuilt as an installable extension package.

• Provider registry as extension (BYOK chain, model catalog)
• Completion streaming via Starlark provider.complete
• Personas as extension data
• Channel/message storage via ext_data tables
• Tool system as extension hooks

v0.5.0 — MVP

Extension and operations tracks converge. First externally usable release.

• Package registry (browse, install, update, uninstall)
• Extension marketplace foundations
• Health monitoring dashboard
• Backup/restore tooling
• Documentation site

Post-MVP

• Rich media extensions: image generation, code sandbox, STT/TTS
• Desktop app (Tauri or Electron)
• Sidecar tier: container-based extensions
• Federation: cross-instance package sharing
• Plugin marketplace with signing and review

Design Decisions Log

Decision	Rationale
Tasks → extension	Scheduler was the most entangled kernel component (~3,400 lines). Rebuilding as extension validates the trigger system and removes the worst compilation debt. Three trigger primitives (time, webhook, event) replace the monolithic scheduler.
Sessions removed	Channel-based sessions coupled to deleted chat system. Workflow instances need new storage model — either ext_data tables or a dedicated kernel table.
chat_only → custom	Stage mode chat_only implied chat as a kernel concept. Renamed to custom which delegates to a surface package, proving extension composability.
Providers removed from kernel	Provider configs, model catalog, routing policies — all moved to extension track. Kernel provides credential storage (connections) and the Starlark provider.complete module as the interface.
Kernel permissions simplified	From 16 chat-centric permissions to 6 platform permissions. Extensions define their own capability requirements in manifests.
Preact+htm retained	3KB runtime, no build step, works for extension authors without bundler config. KISS.
Single Docker image	Drop the frontend/backend split. Go binary + assets + migrations in one image. Simpler deployment, fewer moving parts.